gifts2017

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

Опубликовал Рыбаков Алексей (Fisha) в раздел Администрирование - Защита, права, пароли

RLS Изменение отрабатывается 2 раза

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

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

ГДЕ 
      ВЫБОР
            КОГДА ПометкаУдаления <> Ссылка.ПометкаУдаления ТОГДА
                  НЕ Ссылка.ПометкаУдаления
            КОГДА Проведен <> Ссылка.Проведен ТОГДА
                  НЕ Ссылка.Проведен
            КОГДА Реквизит <> Ссылка.Реквизит ТОГДА
                  НЕ Ссылка.Проведен
      
      ИНАЧЕ ИСТИНА
      КОНЕЦ

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

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

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

Спасибо за внимание.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. al petrov (petrov_al) 31.05.14 13:30
спасибо за информацию...
2. Сергей (avasl) 04.06.14 10:35
В доке это описано:

"Для операции изменения ограничению доступа к данным должен соответствовать объект как до изменения (чтобы объект был прочитан), так и после изменения (чтобы объект был записан)."
http://its.1c.ru/db/v83doc#content:63:1
3. Кирилл Бондаренко (karapuzzzz) 04.06.14 11:09
Даже не задумывался над этим. Но спасибо большое за информацию - очень полезно.

<offtop>
Понравилась конструкция:

Однажды, мое руководство придумало, как организовать работу продавца

Уже это сделало мое рабочее утро.
</offtop>
4. Мастер Йода (master_yoda) 06.06.14 10:27
Первые два предложения смеялся, упал под стол, оттуда и пишу сейчас
5. Андрей Киреев (FractonKireyev) 06.06.14 14:20
Красиво с точки зрения выполнения задачи.
И с юмором.
6. Роман Озеряный (rozer) 06.06.14 16:26
7. a exeel (aexeel) 13.06.14 20:00
Не думаю, что пометка на удаление документов продавцами очень уж частая операция. В то время как мех-м РЛС будет отрабатывать для каждого события записи. Как вариант, можно было бы ограничить изменение проведенных документов штатными правами, а к документу(ам) подключить команду пометки на удаления в привелигированном режиме.
8. Владимир Кузнецов (mr.Kot) 27.06.14 11:16
Жесткое руководство. Продавцам работать теперь один стресс будет
9. BabySG (BabySG) 27.06.14 15:52
Первым проходом ПередЗаписью проверяются неравенства с атрибутами еще не записанного объекта

Записи в базе нет, но мы уже ломимся ее проверять? В скуле смотрели, какие запросы возникают и сколько раз? Что там показывают?
Я вот не очень понимаю, какие атрибуты НЕЗАПИСАННОГО объекта мы проверяем.
10. г. Казань Рустем Гумеров (Rustig) 03.07.14 15:14
(0) RLS красиво работает на ограничение в правах на чтение, когда по какому-нибудь контрагенту пользователь не имеет право видеть информацию (на примере БП 2.0 КОРП)
А в остальных ситуациях не пробовал применять RLS.
В УТ 11 и без них запутанные взаимосвязи прав доступа: профили, группы доступа и т.д.
Чаще я встречался с различно рода механизмами ограничения прав: иерархия прав пользователей через регистр сведений, ограничение на статусы документа, добавление поля Автор документа к уже имеющемуся полю Ответственный и т.д.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа