Исходные данные:
Есть платформа 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 раз. Опытным путем было установлено, что само выполнение запроса к БД происходит непосредственно во время вывода таблицы:
|
1 2 3 4 |
// выполняем запрос без учета RLS УстановитьПривилегированныйРежим(Истина); ПроцессорВывода.Вывести(ПроцессорКомпоновкиДанных); УстановитьПривилегированныйРежим(Ложь); |
Здравствуйте!
Нельзя ли более подробно раскрыть алгоритм, так скажем для “Чайника”, к которым себя отношу, чтоб исполнить это в 1С ЕРП?
(целый месяц в одиночестве пытаюсь сделать, то что раскрыто в этой замечательно и актуальной статье, но всё выглядит бесперспективно).
Буду рад любому комментарию, который поможет мне исполнить задуманное в этой статье.
Спасибо!
Здравствуйте, уже несколько лет не занимаюсь 1С. Тем не менее, перечитал свою статью, и насколько помню, все получилось как описано в пункте 6.
Т.е. с использованием отчета и включением привилегированного режима, которому пофиг на ограничения доступа.
Создаем нужный отчет для отображение всех контрагентов/партнеров. Но формируем его программно из кода, чтобы иметь возможность сначала установить привилегированный режим ПЕРЕД непосредственным запросом в базу, а потом сразу отключить его, чтобы юзер уже не смог воспользоваться временным полным доступом к объектам.
Ну т.е. получилось все сделать, по сути, в 3 строчки (не считая остальных “потрохов” по созданию и отображению самого отчета).