Установка даты запрета изменения данных без монопольного режима

Обработка позволяет изменить дату запрета изменения данных без перехода в монопольный режим.

Это несколько модифицированная обработка из Бухгалтерии 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: Для того чтобы пользователю не нужно было перезаходить в базу, нужно по таймеру или какому-либо событию выполнять комману у пользователя:

ПолныеПрава.УстановитьПараметрГраницыЗапретаИзмененияДанных();

Сделать такое из обработки для всех пользователей не возможно, так как доступ к ПараметрамСеанса есть только из сеанса пользователя.

27 Comments

  1. hulio

    данная обработка — всего лишь интерфейс для редактирования регистра сведений «Граница запрета изменения данных». Данный регистр можно открыть через меню «Операции —> регистры сведений» и отредактировать без использования обработки. В таком случае проверки на монопольный режим не будет.

    Но ключевая фраза — «применятся ограничения только при новом входе пользователя». То есть, даже с использованием обработки автора пользователей все равно нужно выгонять, чтобы их параметры сеансов обновились.

    В общем, не ставлю ни плюс, ни минус 🙂

    Reply
  2. ASUAndy

    Ну да, это всего лишь интерфейс… Кстати документы — это тоже всего лишь интерфейс к регистрам 🙂

    Выгонять надо. Но если изменения затрагивают только одного пользователя, то нужно выгнать только его. А это проще чем 20-30-50 пользователей…

    Кстати, если воспользоваться обработкой из конфигурации, которая требует монопольного доступа и изменить границу для пользователя который её меняет, то изменения вступят в силу ТОЛЬКО при его следующем входе. Так что монопольный доступ ничего не даёт.

    Reply
  3. Dimkasan

    hulio, спасибо 🙂 я не задумывался, что можно просто регистр сведений отредактировать. Часто бывает, что нужно дату запрета поставить, что бы с завтрашнего дня запрет вступил в силу, а в течении сегодняшнего дня работу пользователей, как правило, прерывать нельзя. Поэтому приходилось дожидаться окончания рабочего дня 🙂

    Reply
  4. Coollerok

    Спасибо! а то надоело всех разгонять для установки даты запрета))

    Reply
  5. vovkakursk

    Спасибо!

    Reply
  6. nu_fguz_buh

    Спасибо! Хоть у нас и не много пользователей и разгонять всех не так трудно как у других, но все равно ОЧЕНЬ УДОБНО.

    Reply
  7. Гость

    как резюме. Получается что пользователей можно не выгонять, но и обработка особо не нужна. Достаточно только регистр «Граница запрета изменения данных» отредактировать, «перезайти» нужному пользователю и для него применится новая граница? или только когда все выполнят повторный вход в систему?

    Reply
  8. ASUAndy

    (7) Валера, в принципе обработка — это «оболочка» для редактирования регистра сведений. Можно и регистр править без обработки. А ограничения вступят в силу при ВХОДЕ того пользователя, которого они касаются. Т.е. даже если пользователь из базы не выйдет, а войдёт ещё раз под тем же именем, то при втором входе ограничения уже будут действовать. Всем выходить не нужно.

    Т.е. Граница запрета изменения данных «считывается» при входе пользователя.

    Reply
  9. Гость

    Спасибо. вот теперь все понятно:)

    Reply
  10. sstar90

    Вообще то пользователя, для которого изменили дату запрета изменения данных, можно и не выгонять.

    Например, в Бухгалтерии можно воспользоваться, в полном интерфейсе, «Сервис» -> «Служебные» -> «Обновить служебную информацию»

    Reply
  11. ASUAndy

    (10) sstar90, Спасибо! Про обновление служебной информации не знал… Мне это не нужно, но если кому-то надо, то могу доделать обработку, чтобы она применяла ограничения всем пользователям без перелогина.

    Reply
  12. ASUAndy

    (11) Из обработки применить ГраницуЗапретаИзмененияДанных для всех пользователей не получилось, так как доступ к ПараметрамСеанса пользователя есть только из сеанса пользователя. Но по таймеру или событию можно применить ГраницуЗапрела без перелогина. Смотрите публикацию, в низу под словом UpDate я описал как.

    Reply
  13. Necytij

    (12)

    Ну кто же так делает, уважаемый? Насоветуете тут… И вот сидят 150 пользователей в базе, у которых каждые 5 секунд вызывается установить границы изменений… не солидно как то. Может лучше флаг хоть какой организовать, а?

    Reply
  14. ASUAndy

    (13) Necytij, ну про таймер это я для охвата всех возможных вариантов 🙂

    Понятно что таймер не хорошая идея, а под «событием» я и имел в виду использование флагов, открытие журнала или ещё что-то.

    Reply
  15. Coollerok

    Спасиюо за обработку. Пригодилось! а то уже надоело постоянно чтобы поставить дату выгонять всех пользователей

    Reply
  16. qux

    Спасибо хорошая обработка.

    Reply
  17. higs

    И ведь вот знаю про регистр сведений, но несколько надоедает по нему ходить и править. Пусть будет обработка, спасибо!

    Reply
  18. a4a

    Дата запрета редактирования не монопольно — вопрос, который неожиданно всплыл в самый неподходящий момент и срочнее некуда. И всего лишь маленький нюанс, связанный с оперативным обновлением системной информации через меню «Сервис» снимает кучу проблем, связанных с отключением пользователей. Спасибо автору за поднятие актуальной темы. Плюс.

    Reply
  19. c_andrey

    Добрый вечер.

    Очень помогла ваша обработка. Но возникла необходимость использовать её для нескольких пользователей или на нескольких групп пользователей.

    Подскажите как её изменить для этой цели.?

    Зарание Спасибо.

    Reply
  20. ASUAndy

    (19) c_andrey, её не надо менять — это я на скриншоте показал для одного пользователя, а так там есть кнопка добавить и можно добавлять сколько надо пользователей и групп.

    Reply
  21. Alex_E

    Что самое интересное, что после редактирования границы запрета выгонять пользователей совсем необязательно, изменения вступят в силу без монопольного режима, нужно просто через Сервис — Служебные — Обновить системную информацию и перезапускать программу пользователю не понадобится….

    Reply
  22. ASUAndy

    (21) Alex_E, про это написано в самом первом «Лучшем комментарии»…

    Reply
  23. Alex_E

    (22) Круто! Простите, не заметил… Плюсанул 🙂

    Reply
  24. c_andrey

    Все верно. Добавляем Петю Васю и Сережу.

    А в вашей обработке- в коде участвует одна запись (В самом начале кода).

    Т.е если я завожу в обработке троих «в начале кода» то сменится дата только у последнего Сережи.

    Потому что мы по очереди присваиваем имена одной и той же строчке.

    В чем и суть у меня, что я не могу сразу троим одинаковую дату присвоить

    Reply
  25. ASUAndy

    (24) c_andrey, Понял, проверю… если действительно так, то исправлю и выложу новую версию…

    Reply
  26. ASUAndy

    (24) c_andrey, Обновил «Пример обработки установка даты запрета изменения данных из скрипта» теперь там пользователи задаются в таблице значений и для каждого можно указать свою дату запрета. Пользователи задаются непосредственно в обработке, так как это всего лишь пример — если нужно, то можно хранить их в регистре сведений, файле, базе данных или ещё где придумаете…

    p.s. Не знаю как правильно менять файл в публикации, поэтому дата у файла не изменилась, но файл точно новый — я проверил 🙂

    Reply
  27. c_andrey

    (26) Спасибо

    Качаю сейчас проверю.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *