gifts2017

Установка даты запрета изменения данных БЕЗ УСТАНОВКИ МОНОПОЛЬНОГО доступа (для БП 1.6)

Опубликовал Валерий Гайдабура (director04) в раздел Администрирование - Системное

Данная обработка позволяет устанавливать дату запрета изменения данных пользователями, БЕЗ УСТАНОВКИ МОНОПОЛЬНОГО режима (то бишь без изгнания пользователей, работающих с информационной базой).
Проверена на БП 1.6 (1.6.17.4)

За основу взята штатная обработка конфигурации БП 1.6. Изменения минимальны.

Необходимость данных изменений возникла, в связи с позицией группы разработки БП (или вопреки ей), что установка даты запрета, может быть проведена только после гарантированного изгнания ВСЕХ пользователей базы данных (обуславливается тем, что изменения вступают в силу после перезапуска 1С текущим пользователем системы).

В моей организации это порядка 70 человек единовременно. Во время квартальной отчетности изгнание их из базы данных среди белого дня - сравни самоубивству...... Вот и пришлось изобретать велосипед.

Если кого заинтересует - прошу любить и жаловать.

PS:Спасибо - это много, достаточно плюсика!

Скачать файлы

Наименование Файл Версия Размер
Установка даты запрета изменения данных 248
.epf 20,77Kb
02.10.09
248
.epf 20,77Kb Скачать

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение
Комментарии
1. Saw (Re:аниматор) 21.08.09 09:49
>обуславливается тем, что изменения вступают в силу после перезапуска 1С текущим пользователем системы

смысл устанавливать если действия после перезапуска 1С пользователем?

дата запрета будет установлена, но пользователь не перезапуская сеанс может и поменять закрытый период
2. Валерий Гайдабура (director04) 21.08.09 10:07
(1) Именно такой смысл имеется в конфигурации ЗУП 2.5. Это там организовано именно так и ни как иначе. Спорить можно до зеленых соплей. Если не нравится - можно пользоваться штатной. Но, если нравится, то:
допустим в базе данных работает куча бухов и уйти домой (всвязи с квартальным отчетом) скоро не собирается. Но кто-то самый умный уже закончил отчетность и желает выставить запрет.
У администратора три варианта:
- собачиться с отстающими и выгонять их из базы (пользуясь штатной обработкой)
- оставаться на работе до ухода последнего двоешники (буха)
- установить дату запрета данной обработкой (и на следующее утро дата начнет уже действовать)

Выбирать вам.
3. Saw (Re:аниматор) 21.08.09 10:52
> ... и на следующее утро дата начнет уже действовать)

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

если ночью не работают, то наверное имело бы место закрывать автоматически ночью тогда, есть же механизм регламентных заданий.

а есть бухгалтера которые не выходят, сеанс может висеть не сколько дней и когда же у него наступит утро?
4. Валерий Гайдабура (director04) 21.08.09 11:15
(3) Ну уважаемый, если у вас все так запущено, то вам действительно противопоказана данная обработка..... Выбирайте пункт 1-й
5. Saw (Re:аниматор) 21.08.09 11:38
(4) у нас все ОК, продуман механизм закрытия, а вот с вашим решением будут косяки (накосячат во время так называемого закрытия, а утром и не исправят), просто хочу сказать что бесполезная обработка, вот и всё.

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

оставил свое мнение, без рецензии. асталависта!
6. Gamm (Gamm) 21.08.09 12:33
Для корректной работы данного алгоритма, необходима прописать периодическую процедуру на клиенте которая каждые 3 минуты если были изменения обновляет параметр сеанса с Границами запрета.
7. Dmitry Chernykh (dim0n_la) 23.08.09 13:53
Была похожая проблема.
Убирал монопольный режим установки даты запрета.
Для контроля был создан регистр сведений, который содержал список пользователей с обновленной датой запрета.
При установке даты запрета регистр необходимо очистить.
Далее в подписке на событие организованной для даты запрета (в БУ это "ПередЗаписьюДокументаДатаЗапретаРедактирования") нужно добавить проверку, есть ли пользователь в данном списке.
Если нет запускаю процедуру установки даты запрета для конкретного пользователя. дальше идет все своим чередом, т.е. проверяется дата запрета и в зависимости от нее проводится или не проводится документ.
Как вариант реализации. Просто тогда показалось, что будет лучше так, чем нагружать систему каждые несколько минут считывать параметрсеанса пользователя, которые итак очень медленно работают.
sidorov8; +1 Ответить
8. kitt al;dskjf;ldasjkf (kitt) 01.09.09 02:46
Те кто не видит смысла в данной обработке, не забывайте что бывает распределенка основанная на организациях. То есть каждый филиал это отдельная организация. И когда нужно установить дату запрета в филиалах (то есть на работающих в главной базе сотрудниках это никак не отразиться, у них другая организация) то всё равно нужно чтобы сотрудники главной базы выходили, хотя они тут не сном, ни духом.
9. kitt al;dskjf;ldasjkf (kitt) 01.09.09 02:55
А разработчиков типовой БП нужно долго бить молотком по пальцам, за алгоритм, при котором дата запрета изменения данных считывается только один раз за сеанс работы.
mtv:); munster; +2 Ответить
10. Алексей (Alav) 04.10.09 23:22
А почему просто нельзя зайти в РС и установить ручками. И выгонять никого не надо
11. Наталья (valya977) 28.12.09 06:33
Спасибо очень пригодилась,особенно в общепите!
12. Галина Злобина (gala2009) 07.10.11 18:32
13. Андрей Макаров (XOCTEP) 05.05.14 11:00
Спасибо, после конвертации работает на 2.0