Разработать возможность ограничивать доступ к редактированию определенных видов документов по истечении назначенного срока. Список документов с данным ограничением и срок доступа должен быть доступен для изменения администратором либо начальником.
Реализация:
1 . Так как список документов с ограничением должен быть доступен для изменения, необходимо его создать. Выбор пал на регистр сведений. Создаем регистр сведений, в котором будем хранить список документов, и открываем к нему доступ для уполномоченных пользователей.
2. Для ограничения доступа только тех документов, у которых дата старше определенного срока, точно будем использовать RLS. Поскольку текущую дату в запросе получить не так-то просто, создадим параметр сеанса, в котором будем хранить дату начала сеанса для пользователя.
3. Создаем константу, в которой будем указывать срок доступности документов по дате. Ну и, конечно же, добавим ее на форму настроек.
4. Пишем шаблон RLS, который будем пихать в документы, которые используются в системе (можно, конечно, повесить на все документы, но это долго, мы цепляли только на документы, которые часто используются и есть смысл ограничивать).
5. Вешаем написанный RLS на нужные роли и в часто используемые документы.
Дополнительная информация: Также в представленном шаблоне RLS имеется фильтр по Ответственному, который запрещает пользователям изменять «чужие» документы, его по желанию можно удалить, вынести в отдельный шаблон или же оставить, если угодно … =)
Пример реализации прикрепляю. Конфигурация содержит маленький кусочек конфигурации с одним документом, одной ролью, Регистром сведений, константой и параметром сеанса, которые приведены выше. Работоспособность можно проверить, перенеся описанный механизм на любую рабочую конфигурацию.
Ограничение редактирования проще через подписку на событие запись делать, как в типовых. RLS это больше для ограничения видимости. А если типовая конфа, тогда тем более роли лучше не трогать.
(1) zqzq,Возможно… А если в системе больше 100 пользователей и их делят больше 10 ролей, будем в подписке на события перебирать все и проверять кому закрыть доступ?…. Как по мне в таком варианте использования RLS нет ничего плохого.
(2) Приведенный Вами аргумент ничего не меняет. Подписка на событие будет работать быстрее в данном случае, так как выполнятся проверка будет на сервере 1С до начала попытки записи и время блокировки объекта будет существенно меньше. Согласен, что RLS целесообразно использовать при ограничении чтения и просмотра данных, а проверки перед записью правильней со всех точек зрения (а особенно как раз в высоконагруженной системе при 100 пользователях и 100 ролях) выполнять в подписке на события.
А то что больше 10(100) ролей — ну так в подписке на событие легко можно делать и более хитроумные проверки — полностью доступны все возможности языка 1С, нет сложностей с тем, что всё надо запихнуть в один универсальный запрос, поэтому даже с точки зрения простоты отладки и возможности реализации нестандартных ограничений — предпочтительней подписка на события. RLS в принципе задумывался как механизм, который исключит всякую возможность именно считывания и просмотра «конфиденциальной» для данной роли информации, когда это «не секъюрно» ограничивать формами, отборами в списках и так далее. В данном случае я считаю применение RLS просто не оправдано.
Отлично, то что и искал. Как раз надо ограничить документы ОтчеОрозничныхПродажах
(1) т.е. вы предлагаете извещать пользователя о том, что ему запрещено редактирование документа только при записи? Оригинально. Представьте, пользователь открывает, полчаса что-то там крыжит, а потом бац — «Вам запрещено редактировать документ старше N-дней!» Думаю, что за такой код можно и в лицо получить