Особенности работы механизма RLS

Однажды, мое руководство придумало, как организовать работу продавца с документами реализации: Давай, говорит, сделай так, чтоб если продавец ошибся при проведении документа, то мог только пометить его на удаление. Автоматически подумалось: надо потыкать галочки в правах. Ан нет! Дело в том, что право Интерактивная пометка на удаление, в случае проведенного документа, противоречит с отсутствием права Интерактивное изменение проведенных. Выходит, что для решения этой задачи надо выдать пользователю, практически, полные права на документ... И я нашел спасение в RLS.

Для меня стало открытием то, что RLS Изменение отрабатывается как минимум 2 раза. Перед записью и при записи. В доказательство сего приведу следующий пример кода ограничения доступа для документа:

Эта конструкция позволяет поставить пометку на удаление, но не позволяет ее снять. Позволяет провести, но не дает отменить проведение. И наконец, не дает изменить Реквизит проведенного документа. Разумеется, перечень «контрольных» реквизитов в условии можно расширить.

Первым проходом ПередЗаписью проверяются неравенства с атрибутами еще не записанного объекта, используя Ссылка.Атрибут, а вторым, ПриЗаписи, когда объект и ссылка разделены только полным окончанием транзакции, проверять уже нечего — ИНАЧЕ ИСТИНА.

Очень было бы заманчиво вместо Реквизит использовать ВерсияДанных. Получилась бы оптимальная проверка на Изменение. Но, к сожалению, версия данных в обоих проходах идентична. Что, в общем, понятно — устанавливать версию данных можно только на уже записанный объект.