Однажды, мое руководство придумало, как организовать работу продавца с документами реализации: Давай, говорит, сделай так, чтоб если продавец ошибся при проведении документа, то мог только пометить его на удаление. Автоматически подумалось: надо потыкать галочки в правах. Ан нет! Дело в том, что право Интерактивная пометка на удаление, в случае проведенного документа, противоречит с отсутствием права Интерактивное изменение проведенных. Выходит, что для решения этой задачи надо выдать пользователю, практически, полные права на документ… И я нашел спасение в RLS.
Для меня стало открытием то, что RLS Изменение отрабатывается как минимум 2 раза. Перед записью и при записи. В доказательство сего приведу следующий пример кода ограничения доступа для документа:
ГДЕ
ВЫБОР
КОГДА ПометкаУдаления <> Ссылка.ПометкаУдаления ТОГДА
НЕ Ссылка.ПометкаУдаления
КОГДА Проведен <> Ссылка.Проведен ТОГДА
НЕ Ссылка.Проведен
КОГДА Реквизит <> Ссылка.Реквизит ТОГДА
НЕ Ссылка.Проведен
ИНАЧЕ ИСТИНА
КОНЕЦ
Эта конструкция позволяет поставить пометку на удаление, но не позволяет ее снять. Позволяет провести, но не дает отменить проведение. И наконец, не дает изменить Реквизит проведенного документа. Разумеется, перечень «контрольных» реквизитов в условии можно расширить.
Первым проходом ПередЗаписью проверяются неравенства с атрибутами еще не записанного объекта, используя Ссылка.Атрибут, а вторым, ПриЗаписи, когда объект и ссылка разделены только полным окончанием транзакции, проверять уже нечего — ИНАЧЕ ИСТИНА.
Очень было бы заманчиво вместо Реквизит использовать ВерсияДанных. Получилась бы оптимальная проверка на Изменение. Но, к сожалению, версия данных в обоих проходах идентична. Что, в общем, понятно — устанавливать версию данных можно только на уже записанный объект.
Спасибо за внимание.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
спасибо за информацию…
В доке это описано:
«Для операции изменения ограничению доступа к данным должен соответствовать объект как до изменения (чтобы объект был прочитан), так и после изменения (чтобы объект был записан).»
Даже не задумывался над этим. Но спасибо большое за информацию — очень полезно.
<offtop>
Понравилась конструкция:
Однажды, мое руководство придумало, как организовать работу продавца
Уже это сделало мое рабочее утро.
</offtop>
Первые два предложения смеялся, упал под стол, оттуда и пишу сейчас
Красиво с точки зрения выполнения задачи.
И с юмором.
Красиво …
Не думаю, что пометка на удаление документов продавцами очень уж частая операция. В то время как мех-м РЛС будет отрабатывать для каждого события записи. Как вариант, можно было бы ограничить изменение проведенных документов штатными правами, а к документу(ам) подключить команду пометки на удаления в привелигированном режиме.
Жесткое руководство. Продавцам работать теперь один стресс будет
Записи в базе нет, но мы уже ломимся ее проверять? В скуле смотрели, какие запросы возникают и сколько раз? Что там показывают?
Я вот не очень понимаю, какие атрибуты НЕЗАПИСАННОГО объекта мы проверяем.
(0) RLS красиво работает на ограничение в правах на чтение, когда по какому-нибудь контрагенту пользователь не имеет право видеть информацию (на примере БП 2.0 КОРП)
А в остальных ситуациях не пробовал применять RLS.
В УТ 11 и без них запутанные взаимосвязи прав доступа: профили, группы доступа и т.д.
Чаще я встречался с различно рода механизмами ограничения прав: иерархия прав пользователей через регистр сведений, ограничение на статусы документа, добавление поля Автор документа к уже имеющемуся полю Ответственный и т.д.