1С: Чтение всех контрагентов при включенном RLS

 
Исходные данные:
Есть платформа 8.3.13.1644, УТ 11.4.
Есть настроенное RLS по группам доступа партнеров.
Т.е. пользователи видят (и тем более могут использовать в документах) только “своих” партнеров/контрагентов.
 
Задача:
Нужно, чтобы юзеры могли видеть ВСЕХ контрагентов/партнеров, но использовать в документах только “своих”.

 
Нюансы:
Уточнение по поводу “видеть всех”. ВСЕ контрагенты должны отображаться только в какой-нибудь отдельной форме/отчете. А в полях выбора документов должны выводиться только “свои”, чтобы не вводить менеджеров в заблуждение.
 

Немного теории:
RLS (Record Level Security) – ограничение доступа на уровне записей и полей.
Еще здесь отличное описание возможностей 1С по управлению доступом.
 
В 1С роли разграничивают общий доступ на объекты, а RLS – разграничивает то, что разрешено ролью, на уровне записей.
RLS является не механизмом запрета доступа, а механизмом фильтрации выдачи доступа.
RLS влияет только на ту конкретную связь “Роль” – “Право доступа”, в которой он прописан. И не влияет на права доступа, выданные с помощью других ролей.
Поэтому если пользователю выдается несколько ролей, то фильтр с помощью RLS нужно ставить в каждой роли.
 
RLS применяется для следующих видов прав доступа (из всех 16-ти):
  • Чтение
  • Добавление
  • Изменение
  • Удаление
Это означает, что нельзя, например, дать пользователю одновременно право “Изменение” без фильтра (для возможности работать программно с любыми документами) и право “Редактирование” с фильтром RLS по организации для интерактивной работы. Если нам нужно, чтобы пользователь мог редактировать документы с фильтром RLS , мы обязаны наложить общий фильтр на верхнем уровне “Изменение” или “Чтение”.
 

Вариант решения с ходу: настроить правила RLS для ролей, открывающих доступ к нужным справочникам.
 
Роли, открывающие нужный доступ:
ДобавлениеИзменениеИнформацииПоПартнерам
ЧтениеИнформацииПоПартнерам
 
В качестве формы для просмотра всех контрагентов использовался демони.. динамический список.
 
Пробовалось:
1) Выпилить правила RLS из нужных ролей для права Чтения.
Точнее: создать копию роли ЧтениеИнформацииПоПартнерам, но без правил RLS для права Чтения. Добавить ее юзеру, рядом с нетронутой ДобавлениеИзменениеИнформацииПоПартнерам.
Результат: юзеры видят и могут выбрать чужих контрагентов в полях выбора. Сохранить, правда, документ не получится – возникнет ошибка прав доступа. Какбэ можно работать и так, но нельзя.
 
 
2) Из роли ДобавлениеИзменениеИнформацииПоПартнерам выпилить RLS для права Чтение. Добавить только эту роль юзеру.
Результат: тот же.
 
3) Экспериментировать с самописными правилами RLS для ролей. Использовать ГДЕ ИСТИНА , ГДЕ ЛОЖЬ , баловаться со списком полей в правиле (как например здесь).
Результат: нулевой. Если у нас используется “глобальное” ограничение записей справочника на изменение, то нужно так же ограничивать и чтение, иначе будет несоответствие видомого и реального. Нельзя в одном месте открыть чтение записей, а в другом закрыть, ведь ограничения “глобальные”. 
 
4) Использовать Параметры сеанса в правилах RLS (спасибо AllexSoft).
“делается параметр сеанса, скажем “ЧтениеВсехОрганизаций” – булево.. при установке сеанса инициализируем его в = Ложь.. делаем новую роль, или на вашу пользовательскую ограниченную роль цепляем RLS на справочник организации – чтение, типа “ГДЕ &ЧтениеВсехОрганизаций”.. ну и в нужном месте (ну скажем в вашем случае при создании на сервере ставим ЧтениеВсехОрганизаций= истина” и все ) не забудьте только сбросить потом параметр сеанса ЧтениеВсехОрганизаций= ложь, когда форму закроют)”
Т.е. создаем булевый параметр сеанса ЧтениеВсехПартнеров. Добавляем его в правила RLS на право Чтения. Устанавливаем его, когда нужно прочитать все записи, затем сбрасываем.
 
Но! Пока параметр ЧтениеВсехПартнеров установлен, то в это время будут доступны чужие контрагенты и в других местах, кроме нашего списка – в документах, например. А
когда его отключать? У динамического списка нет событий ПослеЗагрузкиВсехДанных или что-то в этом роде (на то он и динамический, что подгружает данные по мере отображения). При закрытии формы? При завершении сеанса?:))
Даже если создавать список программно, и запилить включение/отключение параметра до и после кода, все равно это все бестолку – список то динамический.
 
5) Использовать УстановитьПривилегированныйРежим() 
Проблема та же, что и в предыдущем пункте. Когда отключать привилегированный режим?
 
6) Использовать отчет и вызывать УстановитьПривилегированныйРежим()  (или установить ЧтениеВсехПартнеров)
Результат: PROFIT!
С отчетом все просто, он формируется 1 раз. Опытным путем было установлено, что само выполнение запроса к БД происходит непосредственно во время вывода таблицы:

 

0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *