Это несколько модифицированная обработка из Бухгалтерии 2.0.
Возникла необходимость, чтобы у одного пользователя был открыт только сегодняшний день. Была написана обработка, которая выполнялась каждую ночь и устанавливала дату запрета изменения данных на вчерашнее число. (Про регламентные задания знаю, но не хотелать вносить изменения в конфигурацию, да и высчитывать время когда это запускать, чтобы BackUp’у не мешать).
Возникла проблема, что иногда кто-то из пользователей забывал закрыть программу на ночь и тогда период не закрывался. (BackUp не так кретично, а период нужно обязательно закрывать.)
Начал смотреть обработку установки даты запрета изменения данных и обнаружил, что монопольный доступ для этого совсем не обязателен, просто применятся ограничения только при новом входе пользователя.
Ну и как обычно бывает когда закрываешь кому-нибдь доступ, сразу возникают ситуции, когда нужно срочно доступ открывать. Вот и пришлось модифицировать обработку из бухгалтерии, чтобы не выгонять кучу пользователе из базы в течение рабочего дня.
Кстати, мне до сих пор не понятно почему удаление помеченых данных из типовых конфигураций требует монопольного доступа, а обработка с ИТС делает это в разделёноом режиме…
Как бонус выкладываю обработку, котораю двигает границу запрета изменения данных для пользователя на вчерашний день. Её легко модифицировать для группы пользователей, фирмы или общей даты. Но если не получится, то прошу в личку.
Эту обработку можно запускать из скрипта или добавить в регламентные задания.
Коммандная строка для запуска:
«C:Program Files1cv82common1cestart.exe» ENTERPRISE /S»Сервер:1641База» /nПользователь /p»Пароль» /WA- /AU- /DisableStartupMessages /RunModeOrdinaryApplication /AppAutoCheckMode /AppAutoCheckVersion /Execute»C:Program Files
nCronatЗакрытьПериод.epf»
UpDate: Для того чтобы пользователю не нужно было перезаходить в базу, нужно по таймеру или какому-либо событию выполнять комману у пользователя:
ПолныеПрава.УстановитьПараметрГраницыЗапретаИзмененияДанных();
Сделать такое из обработки для всех пользователей не возможно, так как доступ к ПараметрамСеанса есть только из сеанса пользователя.
данная обработка — всего лишь интерфейс для редактирования регистра сведений «Граница запрета изменения данных». Данный регистр можно открыть через меню «Операции —> регистры сведений» и отредактировать без использования обработки. В таком случае проверки на монопольный режим не будет.
Но ключевая фраза — «применятся ограничения только при новом входе пользователя». То есть, даже с использованием обработки автора пользователей все равно нужно выгонять, чтобы их параметры сеансов обновились.
В общем, не ставлю ни плюс, ни минус 🙂
Ну да, это всего лишь интерфейс… Кстати документы — это тоже всего лишь интерфейс к регистрам 🙂
Выгонять надо. Но если изменения затрагивают только одного пользователя, то нужно выгнать только его. А это проще чем 20-30-50 пользователей…
Кстати, если воспользоваться обработкой из конфигурации, которая требует монопольного доступа и изменить границу для пользователя который её меняет, то изменения вступят в силу ТОЛЬКО при его следующем входе. Так что монопольный доступ ничего не даёт.
hulio, спасибо 🙂 я не задумывался, что можно просто регистр сведений отредактировать. Часто бывает, что нужно дату запрета поставить, что бы с завтрашнего дня запрет вступил в силу, а в течении сегодняшнего дня работу пользователей, как правило, прерывать нельзя. Поэтому приходилось дожидаться окончания рабочего дня 🙂
Спасибо! а то надоело всех разгонять для установки даты запрета))
Спасибо!
Спасибо! Хоть у нас и не много пользователей и разгонять всех не так трудно как у других, но все равно ОЧЕНЬ УДОБНО.
как резюме. Получается что пользователей можно не выгонять, но и обработка особо не нужна. Достаточно только регистр «Граница запрета изменения данных» отредактировать, «перезайти» нужному пользователю и для него применится новая граница? или только когда все выполнят повторный вход в систему?
(7) Валера, в принципе обработка — это «оболочка» для редактирования регистра сведений. Можно и регистр править без обработки. А ограничения вступят в силу при ВХОДЕ того пользователя, которого они касаются. Т.е. даже если пользователь из базы не выйдет, а войдёт ещё раз под тем же именем, то при втором входе ограничения уже будут действовать. Всем выходить не нужно.
Т.е. Граница запрета изменения данных «считывается» при входе пользователя.
Спасибо. вот теперь все понятно:)
Вообще то пользователя, для которого изменили дату запрета изменения данных, можно и не выгонять.
Например, в Бухгалтерии можно воспользоваться, в полном интерфейсе, «Сервис» -> «Служебные» -> «Обновить служебную информацию»
(10) sstar90, Спасибо! Про обновление служебной информации не знал… Мне это не нужно, но если кому-то надо, то могу доделать обработку, чтобы она применяла ограничения всем пользователям без перелогина.
(11) Из обработки применить ГраницуЗапретаИзмененияДанных для всех пользователей не получилось, так как доступ к ПараметрамСеанса пользователя есть только из сеанса пользователя. Но по таймеру или событию можно применить ГраницуЗапрела без перелогина. Смотрите публикацию, в низу под словом UpDate я описал как.
(12)
Ну кто же так делает, уважаемый? Насоветуете тут… И вот сидят 150 пользователей в базе, у которых каждые 5 секунд вызывается установить границы изменений… не солидно как то. Может лучше флаг хоть какой организовать, а?
(13) Necytij, ну про таймер это я для охвата всех возможных вариантов 🙂
Понятно что таймер не хорошая идея, а под «событием» я и имел в виду использование флагов, открытие журнала или ещё что-то.
Спасиюо за обработку. Пригодилось! а то уже надоело постоянно чтобы поставить дату выгонять всех пользователей
Спасибо хорошая обработка.
И ведь вот знаю про регистр сведений, но несколько надоедает по нему ходить и править. Пусть будет обработка, спасибо!
Дата запрета редактирования не монопольно — вопрос, который неожиданно всплыл в самый неподходящий момент и срочнее некуда. И всего лишь маленький нюанс, связанный с оперативным обновлением системной информации через меню «Сервис» снимает кучу проблем, связанных с отключением пользователей. Спасибо автору за поднятие актуальной темы. Плюс.
Добрый вечер.
Очень помогла ваша обработка. Но возникла необходимость использовать её для нескольких пользователей или на нескольких групп пользователей.
Подскажите как её изменить для этой цели.?
Зарание Спасибо.
(19) c_andrey, её не надо менять — это я на скриншоте показал для одного пользователя, а так там есть кнопка добавить и можно добавлять сколько надо пользователей и групп.
Что самое интересное, что после редактирования границы запрета выгонять пользователей совсем необязательно, изменения вступят в силу без монопольного режима, нужно просто через Сервис — Служебные — Обновить системную информацию и перезапускать программу пользователю не понадобится….
(21) Alex_E, про это написано в самом первом «Лучшем комментарии»…
(22) Круто! Простите, не заметил… Плюсанул 🙂
Все верно. Добавляем Петю Васю и Сережу.
А в вашей обработке- в коде участвует одна запись (В самом начале кода).
Т.е если я завожу в обработке троих «в начале кода» то сменится дата только у последнего Сережи.
Потому что мы по очереди присваиваем имена одной и той же строчке.
В чем и суть у меня, что я не могу сразу троим одинаковую дату присвоить
(24) c_andrey, Понял, проверю… если действительно так, то исправлю и выложу новую версию…
(24) c_andrey, Обновил «Пример обработки установка даты запрета изменения данных из скрипта» теперь там пользователи задаются в таблице значений и для каждого можно указать свою дату запрета. Пользователи задаются непосредственно в обработке, так как это всего лишь пример — если нужно, то можно хранить их в регистре сведений, файле, базе данных или ещё где придумаете…
p.s. Не знаю как правильно менять файл в публикации, поэтому дата у файла не изменилась, но файл точно новый — я проверил 🙂
(26) Спасибо
Качаю сейчас проверю.