Как правильно настроить rls

Настройка RLS в 1С — ограничение доступа на уровне записей

Ранее мы рассматривали настройку ролей пользователей в системе 1С Предприятие 8, сегодня мы продолжим изучение механизма прав и углубимся далее — в механизм RLS (ограничение прав на уровне записей).

Ниже мы рассмотрим достоинства и недостатки данного метода и рассмотрим настройку RLS в 1С Предприятии 8.3 на примере.

1С RLS (Record Level Security) или ограничение прав на уровне записи — это настройка прав пользователей в системе 1С, которая позволяет разделить права для пользователей в разрезе динамически меняющихся данных.

Самый распространенный вид настройки 1C RLS — ограничение видимости пользователя в разрезе организаций или клиентов (пользователь видит лишь «свои» данные).

Преимущества ограничения прав на уровне записей в 1С

Основное преимущество — наличие механизма вообще, механизм достаточно сложный и интересный. Позволяет очень тонко разграничить права пользователей — пользователи могут даже не догадываться о существовании в системе других данных.

Недостатки 1С 8 RLS

Среди недостатков можно отметить заметное падение производительности системы. Это вызвано тем, что платформа при построении запроса в базе данных осложняет любой запрос разработчика дополнительными условиями.

Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания — попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>

Также среди недостатков — сложность настройки этого функционала и сложность отладки. 1C выпустило очень мало материалов по настройке и работе этого функционала. Достаточно трудно найти специалиста, который грамотно настроил бы механизм.

Настройка ограничения прав на уровне записей 1С RLS

Ограничение прав на уровне записи (RLS) применяется для ограничения следующих типов прав:

##Если &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей ##Тогда

ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
СоставГруппы.Ссылка КАК ГруппаПользователей
ИЗ
Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
ГДЕ
СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ГДЕ (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ЛОЖЬ
ИЛИ (НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1 КАК ПолеОтбора
ИЗ
РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа
ГДЕ
НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
И ВЫБОР
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И ТекущаяТаблица.#Параметр(1) ССЫЛКА Справочник.Контрагенты
И НЕ ТекущаяТаблица.#Параметр(1) = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
ТОГДА ВЫБОР
КОГДА 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
Справочник.Контрагенты КАК Контрагенты ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
ПО
НастройкиПравДоступаПользователей.ОбъектДоступа = Контрагенты.ГруппаДоступаККонтрагенту
И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
И (НастройкиПравДоступаПользователей.Пользователь = НазначениеВидовОбъектовДоступа.ГруппаПользователей
ИЛИ НастройкиПравДоступаПользователей.Пользователь = ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи))
И НастройкиПравДоступаПользователей.Запись = ИСТИНА
ГДЕ
Контрагенты.Ссылка = ТекущаяТаблица.#Параметр(1))
ТОГДА ИСТИНА
ИНАЧЕ ЛОЖЬ
КОНЕЦ
ИНАЧЕ ИСТИНА
КОНЕЦ = ЛОЖЬ))
И НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL)
##КонецЕсли

По сути, этот запрос каждый раз добавляется при запросе к таблице «#ТекущаяТаблица». Из чего можно представить, какую дополнительную нагрузку несет в себе механизм ограничения на уровне записи.

Как Вы видите, в запросе есть специальные параметры, например » &ИспользоватьОграниченияПравДоступаНаУровнеЗаписей». Это параметры в РЛС подбираются из объектов метаданных — «Параметры сеансов«. Как правило, они задаются при старте сессии пользователя.

Конструктор ограничения доступа к данным

Для удобства разработчика в 1С 8.3 есть специальная утилита для помощи в настройки РЛС — Конструктор ограничения доступа к данным. Он вызывается из поля «Ограничение доступа». Выглядит следующим образом:

Другие статьи по 1С:

Пример настройки RLS:

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Источник

Ограничение доступа к данным на уровне записей (RLS) в 1С 8.3

Настройка RLS

Роли позволяют назначить права доступа на весь объект. Но иногда требуется разделить права доступа на конкретные значения объекта. Например, в справочнике контрагентов могут быть и покупатели и поставщики. И нужно, чтобы менеджеры по продажам видели только покупателей, а менеджеры по закупкам только поставщиков.

Для этого используются ограничения доступа к данным на уровне записей или RLS (Record Level Security).

RLS настраиваются в роли в группе Ограничения доступа к данным:

RLS настраиваются отдельно для каждого права. При этом ограничения можно настроить только для следующих прав:

В колонке Поля указывается список полей объекта, на которые настраивается ограничение. Можно выбрать Прочие поля, что значит ограничение на все поля объекта, кроме тех на которые явно настроены ограничения.

Для права Чтение можно настроить несколько ограничений. Между собой они будут объединены по условию И. У пользователя будут права только при выполнении всех ограничений.

На права Добавление, Изменение и Удаление можно настроить только одно ограничение.

Если на какое-то право были настроены RLS, то в списке прав они выделяются цветом, а также пиктограммой:

В примере выше RLS настроены для прав Чтение и Изменение.

Ограничения доступа можно настраивать для:

• Справочников
• Документов
• Журналов документов
• Планов видов характеристик
• Планов счетов
• Планов видов расчета
• Планов обмена
• Регистров сведений
• Регистров накопления
• Регистров бухгалтерии
• Регистров расчета
• Бизнес-процессов
• Задач

Язык ограничения доступа к данным

В колонке Ограничение доступа указывается текст самого ограничения. Он пишется на специальном языке ограничения доступа к данным, который является подмножеством языка запросов 1С. В тексте можно использовать только секции ИЗ и ГДЕ.

Если запрос из ограничения доступа вернет хотя бы одну запись или условие в секции ГДЕ будет истинным, то у пользователя есть права на этот объект базы банных. В противном случае прав не будет.

Простое ограничение доступа может выглядеть следующим образом:

Здесь Контрагенты — это псевдоним таблицы, а ГДЕ ИСТИНА — условие.

Таблица объекта, на который настраиваются ограничения всегда присутствует в тексте запроса. Именно ее псевдоним указывается в начале запроса. При необходимости можно добавить несколько таблиц в запрос:

Можно не использовать условие в запросе . В этом случае, если запрос вернет хотя бы одну запись, то у пользователя будут права на этот объект базы данных:

Стоит отменить что в тексте запроса RLS нельзя обращаться к реквизитам и ресурсам регистра накопления или бухгалтерии. А также можно обращаться только к балансовым измерениям регистра бухгалтерии.

Примеры RLS

Чтобы лучше разобраться как работает RLS в 1С настроим ограничения доступа на справочник Контрагенты, чтобы менеджеры по продажам видели только покупателей.

У справочника Контрагенты есть реквизит ГруппаДоступа, который имеет тип ПеречислениеСсылка.ГруппыДоступаКонтрагентов:

По значению данного реквизита можно определить кем является контрагент.

Сейчас в списке контрагентов 2 покупателя и 2 поставщика:

Создадим роль Покупатели и для справочника Контрагенты и права Чтение настроим следующее ограничение:

И дадим пользователю только эту роль. В результате ему будут доступны только покупатели:

Удалим ограничение доступа для права Чтение и добавим такое же, но для права Добавление:

В результате пользователь может видеть всех контрагентов, но создать нового контрагента может только с группой Покупатели. Если указать любую другую группу, то будет выдана ошибка «У пользователя недостаточно прав на исполнение операции над базой данных»:

Удалим ограничение для права Добавление и добавим такое же для права Изменение:

Теперь пользователь может добавлять контрагентов с любой группой доступа, но изменять может только покупателей. При этом нельзя сначала изменить группу доступа на Покупатели, а потом изменить сам объект. Проверка выполняется как до изменения, так и после изменения.

Удалим ограничения для права Изменение и добавим такое же для права Удаление:

Теперь пользователь может и читать и добавлять и изменять любых контрагентов, но удалить может только покупателей. Именно удалить, а не пометить на удаление.

Вернем снова ограничение только для права Чтение, чтобы пользователь мог видеть только покупателей. Если сейчас пользователю дать еще одну роль, которая дает права на чтение и просмотр контрагентов, но для нее не настроены RLS, то пользователь увидит всех контрагентов. Так происходит, потому что из разных ролей RLS складываются по условию ИЛИ. Если хотя бы в одной роли нет ограничений, то считается, что разрешены все контрагенты.

Если для права Чтение добавить еще одно ограничение с условием:

Источник

Как доработать производительный RLS

Опишу типы задач, в которых потребовалась доработка RLS и приведу примеры реальных задач. В последующих разделах подробно раскрою каждую задачу.

1. Объект должен учитывать типовое ограничение доступа (реальная задача: типовой документ «Реестр платежей» должен содержать типовое ограничение доступа: «Организация»);
2. Расширение типового ограничения доступа на другие реквизиты объекта (реальная задача: типовой документ «Перемещение товаров» должен учитывать типовое ограничение доступа: «Организация» по реквизитам: «Организация» и «ОрганизацияПолучатель»); более подробно как организовать работу между филиалами с включенным RLS будет рассказано в следующей статье.
3. Новое ограничение доступа на типовые объекты (реальная задача: добавить новое ограничение: «Группы финансового учета расчетов» для документа: «Реализация товаров и услуг»).
4. Объект должен учитывать ограничение доступа через другой объект (реальная задача: добавить новое ограничение «Группы финансового учета расчетов» из объекта «Договоры контрагента» для документа «Заказ клиента»).

Объект должен учитывать типовое ограничение доступа

Чтобы объект учитывал типовое ограничение доступа (организация, склад и т.д.), необходимо выполнить ряд следующих действий:

1. В первую очередь новый объект нужно добавить в определяемы тип:

— все объекты добавляем в: ВладелецЗначенийКлючейДоступа

— документы в: ВладелецЗначенийКлючейДоступаДокумент

— справочники в: ВладелецЗначенийКлючейДоступаОбъект

— регистры сведений и регистры накопления в: ВладелецЗначенийКлючейДоступаНаборЗаписей

— регистры расчета в: ВладелецЗначенийКлючейДоступаНаборЗаписейРегистраРасчета

1. В общий модуль «УправлениеДоступомПереопределяемый» в процедуру «ПриЗаполненииСписковСОграничениемДоступа» добавить объект (метаданные).
2. В общий модуль «УправлениеДоступомПереопределяемый» в процедуру «ПриЗаполненииВидовОграниченийПравОбъектовМетаданных» в запрос — добавить объект и вид доступа.
3. Добавить новую роль на чтение нашего объекта. Добавить права на – «Чтение», «Просмотр» объекта.

Скопировать в новую роль типовой шаблон RLS — ДляОбъекта(ПолеОбъекта)

Для права «Чтение» для полей добавить ограничение: #ДляОбъекта(«»)

1. Добавить новую роль на изменение/добавление нашего объекта. Добавить все права, кроме удалений.

Скопировать в новую роль типовой шаблон RLS — ДляОбъекта(ПолеОбъекта)

Для права «Изменение», «Добавление» для полей добавить ограничение: #ДляОбъекта(«»)

1. В модуль менеджера объекта добавить (при её отсутствии):

#Область ДляВызоваИзДругихПодсистем и процедуру

Процедура ПриЗаполненииОграниченияДоступа(Ограничение) Экспорт

в модуле процедуры заполнить — Ограничение.Текст запросом с нужными видами доступа.

1. В форму объекта добавить код в начало процедуры ПриЧтенииНаСервере:

1. В форму объекта добавить код в конец процедуры ПослеЗаписиНаСервере:

1. В пользовательском режиме при создании новых профилей/ групп доступа (с ограничениями) обязательно нужно учитывать, чтобы не добавить типовую роль, на которой отключен RLS (отсутствуют шаблоны ограничений). В следующих статьях я подробно опишу об ограничениях типового RLS .
2. Запустить конфигурацию с параметром: «/c обновление информационной базы» или запустить обработку – «Инструменты разработчика. Обновление Вспомогательных Данных» (можно скачать на сайте ИТС).
3. В пользовательском режиме удалить запись из регистра сведений «Параметры ограничений доступа» (через возможности – «Еще»). В «НСИ и администрирование» — «Настройки пользователей и прав» — «Ограничение доступа на уровне записей», запустить процедуру обновления доступа на уровне записей. При выполнения данной процедуры будут появляться ошибки, если они есть в ограничениях доступа объектов.

Реальная задача: типовой документ «Реестр платежей» должен содержать типовое ограничение доступа: «Организация»:

1. Добавим документ «Реестр платежей» в определяемый тип: ВладелецЗначенийКлючейДоступа
2. Добавим документ «Реестр платежей» в определяемый тип: ВладелецЗначенийКлючейДоступаДокумент
3. В общий модуль «УправлениеДоступомПереопределяемый» в конец процедуры «ПриЗаполненииСписковСОграничениемДоступа» добавил код:

1. В общий модуль «УправлениеДоступомПереопределяемый» в процедуру «ПриЗаполненииВидовОграниченийПравОбъектовМетаданных» в конец запроса добавим следующий код:

1. Добавим новую роль на чтение документа «Реестр платежей», согласно рисунку 1.

Рисунок 1 – Роль «Чтение реестра платежей».

1. Добавим новую роль на добавление/изменение документа «Реестр платежей», согласно рисунку 2.

Рисунок 2 – Роль «Добавление изменение реестра платежей».

1. Добавим в модуль менеджера документа «Реестр платежей» следующий код:

1. В форме документа «Реестр Платежей» добавим в начало процедуры ПриЧтенииНаСервере, следующий код:

1. В форме документа «Реестр Платежей» добавим в конец процедуры ПослеЗаписиНаСервере, следующий код:

1. Создаем новый профиль/группу доступа – «Реестр платежей» (ограничение по организациям) добавляем туда новые роли.

Добавляем в группу доступа пользователей, обязательно проверяем – чтобы не были даны права на документ – «Реестр платежей» без RLS (т.к. в типовых ролях может отсутствовать RLS (шаблоны ограничений доступа)).

1. Запустим обработку – «Инструменты разработчика. Обновление Вспомогательных Данных», выполним все пункты (можно скачать на сайте ИТС).
2. В пользовательском режиме удалить запись из регистра сведений «Параметры ограничений доступа» (через возможности – «Еще»). В «НСИ и администрирование» — «Настройки пользователей и прав» — «Ограничение доступа на уровне записей», запустить процедуру обновления доступа на уровне записей. При выполнения данной процедуры будут появляться ошибки, если они есть в ограничениях доступа документа «Реестр платежей».

Расширение типового ограничения доступа на другие реквизиты объекта

Чтобы расширить типовое ограничения доступа на другие реквизиты объекта, необходимо доработать только в модуле менеджера процедуру – ПриЗаполненииОграниченияДоступа.

В пользовательском режиме при создании новых профилей/групп доступа (ограничение по организациям) – обязательно нужно учитывать, чтобы не добавить типовую роль, на которой отключен RLS (отсутствуют шаблоны ограничений). В следующих статьях я подробно опишу об ограничениях типового RLS .

Реальная задача: типовой документ «Перемещение товаров» должен учитывать типовое ограничение доступа: «Организация» по реквизитам: «Организация» и «ОрганизацияПолучатель».

Изменяем код процедуры «ПриЗаполненииОграниченияДоступа» документа «Перемещение товаров» в модуле менеджера на следующий:

Создаем новый профиль/группу доступа – «Перемещение товаров» добавляем туда роли для документа «Перемещение товаров» или выбираем уже существующий и туда добавляем роли (ограничение по организациям) .

Добавляем в группу доступа пользователей, обязательно проверяем – чтобы не были даны права на документ – «Перемещение товаров» без RLS (т.к. в типовых ролях может отсутствовать RLS (шаблоны ограничений доступа)).

Новое ограничение доступа на объекты

Чтобы типовой объект учитывал новое ограничение доступа, необходимо выполнить ряд следующих действий:

1. Добавить новое ограничение в два определяемых типа:

1. В общий модуль «УправлениеДоступомУТ» в процедуру «ПриЗаполненииВидовДоступа» добавить данные о новом виде доступа.
2. В общий модуль «УправлениеДоступомПереопределяемый» в процедуру «ПриЗаполненииВидовОграниченийПравОбъектовМетаданных» добавить в запросе — данные о новом виде доступа в объекте.
3. В модуле менеджера объекта в процедуру «ПриЗаполненииОграниченияДоступа» добавить необходимый реквизит для ограничения в переменную: Ограничение.Текст
4. В пользовательском режиме при создании новых профилей/групп доступа (с ограничениями) – обязательно нужно учитывать, чтобы не добавить типовую роль, на которой отключен RLS (отсутствуют шаблоны ограничений). В следующих статьях я подробно опишу об ограничениях типового RLS .
5. Запустить конфигурацию с параметром: «/c обновление информационной базы» или запустить обработку – «Инструменты разработчика. Обновление Вспомогательных Данных» (можно скачать на сайте ИТС).
6. В пользовательском режиме удалить запись из регистра сведений «Параметры ограничений доступа» (через возможности – «Еще»). В «НСИ и администрирование» — «Настройки пользователей и прав» — «Ограничение доступа на уровне записей», запустить процедуру обновления доступа на уровне записей. При выполнения данной процедуры будут появляться ошибки, если они есть в ограничениях доступа объектов.

Для добавление нового ограничения доступа на нетиповой объект, нужно выполнить также действия из пункта «Объект должен учитывать типовое ограничение доступа».

Реальная задача: добавить новое ограничение: «Группы финансового учета расчетов» для документа: «Реализация товаров и услуг».

1. Добавить новое ограничение «Группы финансового учета расчетов» в два определяемых типа:

1. В общий модуль «УправлениеДоступомУТ» в процедуру «ПриЗаполненииВидовДоступа» добавим следующий код:

1. В общий модуль «УправлениеДоступомПереопределяемый» в процедуру «ПриЗаполненииВидовОграниченийПравОбъектовМетаданных» добавим следующий код в конец запроса:

1. В модуле менеджера документа «Реализация товаров и услуг» в процедуру «ПриЗаполненииОграниченияДоступа» внесем следующий код:

1. Создаем новый профиль/группу доступа – «Реализация товаров и услуг» добавляем туда роли для документа «Реализация товаров и услуг» или выбираем уже существующий и туда добавляем роли (ограничение по группа финансового учета расчетов) (см. рисунок 3) .

Рисунок 3 – Отображение нового вида доступа: Группы финансового учета расчетов.

1. Добавляем в группу доступа пользователей, обязательно проверяем – чтобы не были даны права на документ – «Реализация товаров и услуг» без RLS (т.к. в типовых ролях может отсутствовать RLS (шаблоны ограничений доступа)).
2. Запустить обработку – «Инструменты разработчика. Обновление Вспомогательных Данных», выбрать все пункты (можно скачать на сайте ИТС).
3. В пользовательском режиме удалить запись из регистра сведений «Параметры ограничений доступа» (через возможности – «Еще»). В «НСИ и администрирование» — «Настройки пользователей и прав» — «Ограничение доступа на уровне записей», запустить процедуру обновления доступа на уровне записей. При выполнения данной процедуры будут появляться ошибки, если они есть в ограничениях доступа документа «Перемещение товаров».

Объект должен учитывать ограничение доступа через другой объект

Чтобы учитывалось ограничение доступа через другой объект в исходном объекте, достаточно в модуле менеджера объекта в процедуре «ПриЗаполненииОграниченияДоступа» добавить следующую конструкцию в переменную Ограничение.Текст:

В пользовательском режиме при создании новых профилей/групп доступа (с учетом нужного ограничения) – обязательно нужно учитывать, чтобы не добавить типовую роль, на которой отключен RLS (отсутствуют шаблоны ограничений). В следующих статьях я подробно опишу об ограничениях типового RLS .

Реальная задача: добавить новое ограничение «Группы финансового учета расчетов» из объекта «Договоры контрагента» для документа «Заказ клиента»

Добавим в модуле менеджера документа «Заказ клиента» в процедуру «ПриЗаполненииОграниченияДоступа» следующий код:

Создаем новый профиль/группу доступа – «Заказ клиента» добавляем туда роли для документа «Заказ клиента» или выбираем уже существующий и туда добавляем роли (ограничение по группам финансового учет расчетов) .

Добавляем в группу доступа пользователей, обязательно проверяем – чтобы не были даны права на документ – «Заказ клиента» без RLS (т.к. в типовых ролях может отсутствовать RLS (шаблоны ограничений доступа).

Тестирование описанных доработок проводил на конфигурации: 1С:ERP. Управление холдингом (3.1.4.31). Но это применимо и для всех остальных конфигураций, которые поддерживают производительный RLS .

Источник