При описании механизма ограничения прав доступа на уровне записей часто используют сокращение RLS от английского Record Level Security. В типовых конфигурациях необходимо обеспечить разделение прав доступа как на уровне таблиц базы данных, так и на уровне отдельных записей каждой таблицы. В данном материале рассматриваются только механизмы разделения доступа пользователей на уровне записей. Основной задачей реализации данного механизма является ограничить доступ пользователя к записям таблиц информационной базы, как на чтение, так и на запись. Например, менеджеру по продажам должны быть доступны для просмотра и редактирования только «его» покупатели и вся связанная с ними информация (документы, контактная информация, переписка по эл.почте и пр.).

Определение ролей.
Состав ролей типовой конфигурации должен соответствовать прикладным потребностям в ограничении прав доступа пользователей к данным. Роли должны быть созданы согласно рабочим местам пользователей, работа которых предполагается с конфигурацией. Проектируя состав ролей конфигурации, необходимо стремиться к тому, что бы одному пользователю была назначена только одна роль, или методически требуемые ограничения прав доступа могли обеспечиваться минимальным набором ролей для одного пользователя. В этом случае будет минимизирован конкурентный доступ пользователя к одной таблице базы данных «через несколько ролей» механизмом ограничения доступа к данным на уроне записей.

Для каждого рабочего места «Менеджер по продажам», «Кассир» и пр., в конфигураторе создаются 2 роли. Например, для рабочего места менеджера по продажам это будут МенеджерПоПродажам и МенеджерПоПродажамСОграничениемПравДоступа. Для роли МенеджерПоПродажам доступ настраивается только на уровне таблиц информационной базы. Для роли МенеджерПоПродажамСОграничениемПравДоступа доступ на уровне таблиц информационной базы должен совпадать с настройками для роли МенеджерПоПродажам, но также должны быть написаны специальные условия ограничения прав доступа на уровне записей. Такие роли будем называть «парой ролей».

Для каждой пары ролей в конфигурации должна выделяться некоторая область данных, с которой пользователь этого рабочего места должен работать. Под областью данных понимается некая совокупность таблиц базы данных, к которым необходимо настроить доступ роли с ограничением прав доступа на уровне записей. Необходимо в режиме 1С:Предприятия обеспечить механизм настройки прав доступа через определенные объекты конфигурации – объекты настройки прав доступа, к таблицам всей области данных. Например, для роли МенеджерПоПродажамСОграничениемПравДоступа объектом настройки прав доступа являются элементы справочника Контрагенты, для роли КассирСОграничениемПравДоступа – справочник Кассы.

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

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

Хранение данных о настройках доступа.
Данные об ограничении прав доступа хранятся в специальном непериодическом регистре сведений ПраваДоступаПользователей:Измерения:
- ОбъектДоступа, ссылки на объекты информационной базы, которые являются объектами настройки прав доступа
- ОбластьДанных, ПеречислениеСсылка.НаборПравПользователей
- Пользователь, СправочникСссылка.Пользователи, СправочникСсылка.ГруппыПользователей
Ресурсы:
- Запись, Булево
Реквизиты:
ВидНаследованияПравДоступаИерархическихСправочников - ПеречислениеСсылка.ВидыНаследованияПравДоступаИерархическихСправочников

В качестве пользователя можно выбирать как элемент справочника Пользователи, так и группу пользователей из справочника ГруппыПользователей.
Данные регистра по каждому объекту настройки прав доступа должны редактироваться или в форме самого объекта, или в отдельной форме, которая вызывается из формы объекта. Присутствие записи в регистре сведений без установленного флажка «Запись» означает, что разрешены права на чтение данных настроенные через текущий объект.

Настройка доступа через объекты настройки прав доступа, являющиеся иерархическими справочниками.
Для иерархических справочников, элементы которых являются объектами настройки прав доступа, необходимо иметь возможность задавать права доступа ко всем подчиненным элементам справочника через родителя. Например, для справочников Контрагенты или Сотрудники. Для этих целей в регистре сведений ПраваДоступаПользователей существует реквизит ВидНаследованияПравДоступаИерархическихСправочников типа ПеречислениеСсылка.ВидыНаследованияПравДоступаИерархическихСправочников.- НаследуетсяОтРодителя- РаспространитьНаПодчиненных- ТолькоДляТекущегоПраваСписокСостав перечисления из которого можно выбирать описываемый параметр при настройке прав доступа, формируется программно по следующим правилам:Для иерархических справочников с иерархией групп и элементов:- Для группы можно устанавливать только «РаспространитьНаПодчиненных»
- Для элемента можно устанавливать только «ТолькоДляТекущегоПрава»

Для иерархических справочников с иерархией элементов:
- Для элементов можно устанавливать «ТолькоДляТекущегоПрава» или «РаспространитьНаПодчиненных»

Для неиерархических справочников:
- Для элементов можно устанавливать ТолькоДляТекущегоПрава

При записи элемента справочника, для которого в записях прав доступа значение реквизита установлено РаспространитьНаПодчиненных, производится запись аналогичных прав доступа для всех элементов текущего родителя, но реквизиту ВидНаследованияПравДоступаИерархическихСправочников устанавливается значение НаследуетсяОтРодителя.
Если для объекта, в записи настройки прав доступа значение реквизита установлено в НаследуетсяОтРодителя, то эту запись изменять в форме текущего объекта нельзя, а можно лишь у родителя, через которого текущая запись создана.

Параметры сеанса пользователя.
Для обеспечения работоспособности механизма ограничения прав доступа на уроне записей в конфигурации должны присутствовать следующие параметры сеанса:- ГруппыТекущегоПользователя, фиксированный массив. Массив должен заполняться при начале работы системы и содержать следующие данные: - Ссылку на предопределенный элемент «Все пользователи» справочника ГруппыПользователей - Ссылку на элемент справочника Пользователи, соответствующий текущему пользователю системы - Ссылки на элементы справочника ГруппыПользователей, в состав которых входит текущий пользователь системы. - Параметры сеанса со всеми определенными областями доступа пользователей. Этим параметрам сеанса должны устанавливаться имена в соответствии со следующим правилом: «ОбластьДанных» + имя области данных как оно задано к конфигураторе в перечислении НаборПравПользователей в родительном падеже. Например, ОбластьДанныхМенеджераПоПродажам или ОбластьДанныхБухгалтера.Параметры сеанса должны заполняться в специальном общем модуле ПолныеПрава, для которого должен быть установлен флажок Привилегированный. Для всех пользователей должны быть сняты права на изменение всех параметров сеанса. Параметры сеанса, которые могут изменяться в течение одного сеанса работы пользователя (например, ГруппыТекущегоПользователя), необходимо иметь возможность обновлять каждому пользователю самостоятельно. Например, при нажатии кнопки «Обновить параметры текущего сеанса» в форме элемента справочника «Пользователи». В этом случае при изменении состава группы пользователей, или вводе новой группы, нет необходимости перезапускать программу, а достаточно обновить параметры сеанса каждому пользователю самостоятельно.

Требования к полям таблиц базы данных.
Каждая таблица базы данных, для которой производится настройка прав доступа на уровне записей, должна содержать поле, данные которого используются для проверки условия ограничения прав. Например, в документе РеализацияТоваровУслуг это может быть «Контрагент»- для менеджера по продажам, «Организация» - для бухгалтера. Для документов РасходныйКассовыйОрдер, ПриходныйКассовыйОрдер» это реквизит «Касса» для ролей «Кассир» и «Кассир ККМ». Для таких реквизитов (измерений и пр.) объектов конфигурации обязательно должен быть установлен признак индексирования «Индексирование» или «Индексировать с доп.упорядочиванием».Если реквизит (измерение, свойство Владелец и пр.), через который производится ограничение прав доступа, имеет составной тип, то для механизмов RLS вводятся дополнительные реквизиты несоставного типа. Данные в эти служебные реквизиты заполняются в модуле объекта, в обработчике события ПередЗаписью(). Для этого должен быть написан специальный алгоритм в модуле каждого объекта.

Принципы написания запросов на условия ограничения прав доступа (RLS-запросов).
Приведем примеры написания условий ограничения прав доступа для роли «Менеджер по продажам» объекту Документы.РеализацияТоваровУслуг исходя из всего вышеописанного.Ограничение прав доступа на чтение:

Ограничение прав доступа на запись:

Особенности определения состава полей таблиц базы данных для условий ограничения доступа на чтение.
При работе пользователя с динамическими списками информация в формах списков справочников, документов и пр. будет отображаться с учетом условий ограничения прав доступа на чтение. Если на выполнение RLS-запроса потребуется достаточно большое время, то формы списков будут открываться с видимым для пользователя замедлением, что приведет к дискомфорту в работе с конфигурацией.

Если в списке содержаться только те поля таблицы базы данных, для которых не указано условие ограничения прав доступа (равнозначно, что в условии написано «ГДЕ ИСТИНА»), то условия ограничения не будут использоваться при заполнении табличного поля, данными из информационной базы. Это исключит замедление отображения данных в табличных полях. При разработке условий ограничения данных и проектировании табличных полей динамических списков необходимо учитывать эту особенность.

Например, для справочника «Контрагенты» в табличном поле отображать только информацию, которая не является закрытой (наименование, код и пр.). Ограничения прав доступа на чтение задавать для всех полей, кроме присутствующих в табличных полях списков справочника. В этом случае в списке будут отображаться все контрагенты, но открыть форму можно будет только тех объектов, доступ на чтение остальных полей которых разрешен.

Описанная модель дает возможность простого изменения поведения табличных полей. Достаточно для определенной роли изменить состав полей, для которых не задано условие ограничения прав доступа на чтение, и в списке будут отображаться только «разрешенные» записи. Можно так же управляя видимостью колонок табличного поля, управлять и режимом отображения записей. При включении видимости колонки, в которой отображаются данные поля с ограничением прав доступа на чтение, начинают работать механизмы RLS и отображаются только «разрешенные» записи. Сокрытие колонок приводит к обратному эффекту. Также, при ограничении доступа к данным на чтение, необходимо понимать следующее:Ограничение доступа на чтение данных из определенных полей может привести к невозможность открытия форм других объектов, проведения документов и пр. Например, у справочника «Контрагенты» есть реквизит «Регион», доступ к которому ограничен механизмами RLS. Доступ к ссылке на элемент справочника Контрагенты – разрешен без ограничения. Если при открытии формы любого другого объекта (допустим документа), в данных которого содержится ссылка на элемент справочника «Контрагенты», требуется получение данных о регионе контрагента из реквизита «Регион», то форма документа не откроется. Хотя доступ на чтение к самому документу может быть полный.