Что такое рлс в 1с

Что такое рлс в 1с

Тема ограничения доступа на уровне записей (RLS) обычно сложна в понимании новичками и многими профессионалами, почему и не используется в работе.
Всего статей будет 2:

1. О том, каким образом платформа обрабатывает RLS; ;

Роли, права доступа

Объект конфигурации «роль» дает набор прав на операции (действия) над объектами конфигурации.

Роль «Полные права».

Это всего лишь роль (не предопределенная), в которой установлены флажки на все виды прав на все объекты конфигурации.

Отличие ее от остальных ролей – наличие права «Администрирование».

В случае создания хотя бы одного пользователя, система начинает проверять наличие права «Администрирование» — оно должно быть минимум у одного пользователя.

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

Row Level Security (RLS) – ограничение на уровне записей.

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

• роли,
• параметры сеанса,
• функциональные опции,
• привилегированные общие модули,
• ключевое слово РАЗРЕШЕННЫЕ в языке запросов.

Механизм предназначен для ограничения доступа к записям таблицы объектов метаданных по произвольным условиям, накладываемым на значения полей строк этих таблиц. Например, чтобы видеть записи только по «своим» контрагентам, организациям и т.д.

Техническая реализация ограничений доступа в 1С

1С формирует запрос к СУБД. Кластер серверов добавляет к запросу секцию ГДЕ, в которой содержится текст условия на ограничение доступа по RLS, затем этот запрос отправляется в СУБД, извлеченные данные возвращаются на клиент 1С.

Такой механизм будет работать при любом запросе из клиента:

• в отчетах,
• в динамических списках и в обычных формах списков
• в произвольных запросах.

Подобная реализация механизма сильно влияет на производительность.

Пути обхода ограничений доступа.

В больших ресурсоемких операциях (обработки перепроведения документов, например) часть кода можно выносить в привилегированные модули.

А) Привилегированный модуль — это общий модуль с флагом «Привилегированный» в свойствах.

Его особенность заключается в том, что код в нем исполняется без какого-либо контроля прав доступа, в том числе и RLS.

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

• Привилегированный режим при проведении
• Привилегированный режим при отмене проведения

В) Метод УстановитьПривилегированныйРежим()

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

Со следующей строки кода будет действовать привилегированный режим исполнения.

Действовать он будет до строки отключения этого режима или до конца процедуры / функции

УстановитьПривилегированныйРежим ( Истина );

// любой код тут будет исполнен без контроля прав и RLS

УстановитьПривилегированныйРежим ( Ложь ); // либо конец процедуры / функции

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

Если в процедуре или функции вызовов метода УстановитьПривилегированныйРежим ( Ложь ) сделано больше, чем вызовов метода УстановитьПривилегированныйРежим ( Истина ), то будет вызвано исключение

Функция ПривилегированныйРежим () возвращает Истина , если привилегированный режим еще включен, и Ложь , если он полностью выключен. При этом не анализируется количество установок привилегированного режима в конкретной функции.

Все вызванные процедуры и функции также будут исполняться в привилегированном режиме.

Также существует возможность стартовать привилегированный сеанс. Это сеанс, в котором привилегированный режим установлен с самого начала работы системы. При этом во время работы метод ПривилегированныйРежим () будет всегда возвращать Истина , а возможность отключить привилегированный режим не поддерживается. Стартовать привилегированный сеанс может только пользователь, которому доступны административные права (право Администрирование). Запуск сеанса можно выполнить с помощью ключа командной строки запуска клиентского приложения UsePrivilegedMode или параметра строки соединения с информационной базой prmod .

Закономерно возникает вопрос: Зачем тогда вообще настраивать ограничения доступа, если его можно так легко обойти?

Безопасный режим.

Да, можно написать внешнюю обработку с привилегированным режимом исполнения и выгрузить / испортить данные. Для предотвращения этого в системе есть метод глобального контекста

Безопасный режим кроме прочего игнорирует привилегированный режим.

Его нужно устанавливать перед программным вызовом внешних обработок или экспортных процедур и функций из их модулей.

При выполнении запрещенных операций во время выполнения генерирует исключение.

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

Настройка ограничения доступа

RLS можно настроить только для прав:

• чтение (select)
• добавление (insert)
• изменение (update)
• удаление (delete)

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

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

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

Для всех остальных прав такой возможности нет.

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

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

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

• Ограничение может быть настроено только для всех полей.
• Ограничение может быть только одно.

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

• в регистрах накопления ограничения доступа могут содержать только измерения основного объекта ограничения;
• в регистрах бухгалтерии в ограничениях можно использовать только балансовые измерения основного объекта ограничения

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

Механизм наложения ограничений доступа.

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

• Формируется список прав (чтение, добавление, изменение, удаление), список таблиц базы данных и список полей, используемых этим запросом.
• Из всех ролей текущего пользователя выбираются ограничения доступа к данным для всех прав, таблиц и полей, задействованных в запросе. При этом если какая-нибудь роль не содержит ограничений доступа к данным какой-нибудь таблицы или поля, то это значит, что в данной таблице доступны значения требуемых полей из любой записи. Иначе говоря, отсутствие ограничения доступа к данным означает наличие ограничения ГДЕ Истина .
• Получаются текущие значения всех параметров сеанса и функциональных опций , участвующих в выбранных ограничениях.

Для получения значения параметра сеанса или функциональной опции от текущего пользователя не требуется наличие права на получение этого значения. Однако если значение некоторого параметра сеанса не было установлено, то произойдет ошибка и запрос к базе данных выполнен не будет.

Ограничения, полученные из одной роли, объединяются операцией И .

Ограничения, полученные из разных ролей, объединяются операцией ИЛИ .

Построенные условия добавляются к SQL-запросам, с которыми «1С: Предприятие» обращается к СУБД. При обращении к данным со стороны условий ограничения доступа проверка прав не выполняется (ни к объектам метаданных, ни к объектам базы данных). Причем механизм добавления условий зависит от выбранного способа действия ограничений «все» или «разрешенные».

* Особенность : Если пользователю доступны несколько ролей с настроенными ограничениями на уровне записей к одному объекту, то в этом случае условия ограничений складываются логической операцией « ИЛИ ». Другими словами полномочия пользователя складываются.

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

Способ «Все».

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

Наложение ограничений доступа способом «все» схематически представлено на рисунке:

Способ «Разрешенные».

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

Ограничения доступа к данным накладываются на объекты базы данных в момент обращения «1С:Предприятия» к базе данных.

В клиент-серверном варианте «1С:Предприятия» наложение ограничений выполняется на сервере «1С:Предприятия».

Однако эта опция (РАЗРЕШЕННЫЕ) не сработает в случае, если мы в запросе обратимся к таблице, для которой не настроены ограничения доступа, но в которой есть ссылки на строки таблицы с настроенными ограничениями. В этом случае результат запроса выдаст «<Объект не найден>…. » вместо значения ссылочного поля.

Если вы разрабатываете отчет или обработку с использованием запросов типовой или самописной конфигурации, всегда ставьте флаг «Разрешенные» , чтобы отчет работал под любым пользователем с любым набором прав.

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

Важно, что если в запросе не указано ключевое слово РАЗРЕШЕННЫЕ, то все отборы, заданные в этом запросе, не должны противоречить ни одному из ограничений на чтение объектов базы данных, используемых в запросе. При этом если в запросе используются виртуальные таблицы, то соответствующие отборы должны быть наложены и на сами виртуальные таблицы.

Производительный режим RLS в 1С

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Оба режима RLS в 1С имеют свои преимущества и недостатки.

RLS в 1С

Для гибкой настройки прав пользователей в конфигурациях на базе БСП (подсистема УправлениеДоступом) реализован механизм настройки доступа на уровне записей (RLS). Этот механизм позволяет ограничивать доступ не только по видам объектов (для конкретных справочников, документов…), но и по данным в этих объектах (т.е., например, ограничить список документов только по одной организации или по конкретному менеджеру).

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в тексте далее.

Для дальнейших скриншотов, примеров кода, а также для решения задачи будем использовать демонстрационную конфигурацию «Библиотека стандартных подсистем», редакция 3.1 (3.1.5.132).

Ограничения RLS описываются в роли для конкретного объекта. Например, ограничение на чтение документа _ДемоСчетНаОплатуПокупателю в роли
_ДемоЧтениеДокументовПокупателей описывается следующим образом:

Как мы видим, для описания ограничений используются специальные шаблоны. В данном случае #ДляОбъекта и #ПоЗначениям. Шаблоны, которые могут быть использованы в роли необходимо описать на вкладке “Шаблоны ограничений”:

В свою очередь, эти шаблоны можно скопировать из поставляемой роли ИзменениеУчастниковГруппДоступа.

Рассмотрим текст ограничения доступа подробнее.

Как мы видим, выбор шаблона зависит от параметра &ОграничениеДоступаНаУровнеЗаписейУниверсально, который как раз и определяет режим, в котором должно использоваться RLS — стандартный или производительный. Значение этого параметра хранится в параметрах сеанса, а в самой базе выбрать режим можно двумя способами:

1. Зайти в раздел Администрирование — Настройки пользователей и прав — Группы доступа — Вариант работы — Производительный

2. В окне “Все функции” изменить значение константы “Ограничивать доступ на уровне записей универсально” на ИСТИНА, если нужен производительный режим и, соответственно на ЛОЖЬ, если стандартный.

Соответственно, если &ОграничениеДоступаНаУровнеЗаписейУниверсально = ЛОЖЬ, то будет использоваться стандартный метод и выполняться код

а если &ОграничениеДоступаНаУровнеЗаписейУниверсально = ИСТИНА, то будет использоваться производительный метод и выполняться код

Подробнее о синтаксисе и использовании шаблонов можно почитать в их описании.

При стандартном режиме ограничение прописывается прямо в роли (установлен отбор по разрешенным организации и партнеру). Эти отборы добавляются к итоговому запросу при обращении к СУБД. При наличии нескольких ролей с описанными ограничениями все условия собираются в один запрос, растет количество левых соединений, повышается риск неправильного использования индексов, выбора неоптимального плана выполнения запроса, что значительно его усложняет и замедляет выполнение. А так как при стандартном режиме работы ограничения рассчитываются “на лету” при каждом обращении к данным (формирование списков справочников и документов, их открытие и записи), то работа пользователя может значительно замедлиться из-за сложности сформированного запроса.

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

Как мы видим, в ограничении роли для производительного режима не описаны никакие условия, нет никакой информации о видах доступа, по которым необходимо ограничивать данные. Где же они указаны? Для этого в подсистеме УправлениеДоступом предусмотрена специальная экспортная процедура ПриЗаполненииОграниченияДоступа(), который описывается в модуле менеджера объекта, указанного в роли.

Так, для документа _ДемоСчетНаОплатуПокупателю эта процедура описана следующим образом:

Здесь мы видим, что ограничение описывается с помощью некоторых типов ограничения (РазрешитьЧтениеИзменение) и функций ограничений (ЗначениеРазрешено()). Это нужно понимать так: пользователю будет разрешено читать и изменять документ _ДемоСчетНаОплатуПокупателю, когда ему будут разрешены значения организации и партнера, указанные в этом документе.

Примечание. Подробно о типах, функциях, синтаксисе ограничений описано на сайте ИТС в разделе — Инструкции по разработке на 1С

— Библиотека стандартных подсистем 3.1.6. Документация

— Глава 3. Настройка и использование подсистем при разработке конфигурации

— Разработка ограничений прав доступа

Далее в статье рассмотрим кратко лишь некоторые.

Некоторые типы ограничений

Типы ограничения могут быть:

• РазрешитьЧтениеИзменение
• РазрешитьИзменениеЕслиРазрешеноЧтение
• РазрешитьИзменение

Основным способом описания ограничений необходимо считать функцию ЗначениеРазрешено(). Функция выполняет поиск проверяемого значения среди разрешенных значений в группах доступа, профили которых предоставляют соответствующие права на список.

• ЗначениеРазрешено(<Реквизит> [<проверяемые типы>] [, <уточнение сравнения 1> [, <уточнение сравнения 2>] …]), где проверяемые типы могут быть (значения непроверяемых типов запрещены, если не уточнены отдельно):

— ТОЛЬКО <Имя таблицы>;
— ТОЛЬКО (<Имя таблицы 1>, <Имя таблицы 2>, … );
— КРОМЕ <Имя таблицы>;
— КРОМЕ (<Имя таблицы 1>, <Имя таблицы 2>, … );

• Уточнение сравнения может быть:

— ПустаяСсылка КАК Ложь/Истина;
— Неопределено КАК Ложь/Истина;
— Null КАК Ложь/Истина;
— Отключено КАК Ложь/Истина (только для функции ЗначениеРазрешено);
— <Таблица> КАК Ложь/Истина (например, Справочник.Проекты КАК Истина).

Также существуют следующие функции:

• ЧтениеОбъектаРазрешено
• ЧтениеСпискаРазрешено
• ИзменениеОбъектаРазрешено
• ИзменениеСпискаРазрешено

Синтаксис этих функций аналогичен функции ЗначениеРазрешено().

Эти функции необходимо использовать, когда необходимо установить доступность (чтение/изменение) объекта в зависимости от доступности его реквизита. Например, документ _ДемоСчетНаОплатуПокупателю должен быть доступен, когда доступен его реквизит Организация. В таком случае ограничение будет описано как:

• ДляВсехСтрок(<Условие>)

Функция выполняет проверку в строках с помощью логического «И». Используется для одновременного выполнения условия во всех строках табличной части объекта.

• ДляОднойИзСтрок(<Условие>)

Функция выполняет проверку в строках с помощью логического «ИЛИ». Используется для выполнения условия хотя бы в одной строке табличной части объекта.

Примеры возможных ограничений

Организация и контрагент в шапке документа:

Организация в шапке документа, контрагент в табличной части, достаточно одного разрешенного контрагента:

Организация в шапке документа, контрагент в табличной части, достаточно одного разрешенного контрагента (если табличная часть пустая, тогда доступ по контрагенту разрешен):

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

Организация и контрагент в табличной части, при этом достаточно, чтобы любая из пар организации с контрагентом была разрешена:

Организация и контрагент в табличной части, при этом требуется, чтобы все пары организации с контрагентом были разрешены:

Организация и контрагент в табличной части, при этом требуется, чтобы одна из организаций и один из контрагентов были разрешены:

Отправитель – измерение составного типа, при этом требуется проверять только ссылки Справочник.Склады:

Отличительная особенность производительного режима RLS в 1С

Вернёмся к основной отличительной особенности производительного режима RLS в 1С. Она заключается в том, что в этом режиме расчет прав происходит предварительно и записывается в специальные таблицы (справочник и регистры сведений). Это позволяет достичь высокой производительности запросов с RLS, так как добавляет простой и статический фрагмент к текстам запросов в ролях. За счет этого обеспечивается одинаково хорошая скорость работы при различной прикладной логике ограничений доступа, при различных условиях и их комбинациях. Но, так как предварительный расчет прав доступа занимает некоторое время, поэтому изменения в правах вступают в силу с некоторой задержкой.

Для хранения этих предварительно рассчитанных данных (ключей) используются следующие таблицы:

• справочник КлючиДоступа
• регистр сведений КлючиДоступаКОбъектам
• регистр сведений КлючиДоступаПользователей

Справочник КлючиДоступа имеет структуру:

В реквизитах Значение1 — Значение5 хранятся комбинации конкретных значений доступа. В зависимости от ограничений каждого конкретного типа объектов конфигурации состав значений разный. Например, как упоминалось выше, для документа _ДемоСчетНаОплатуПокупателю определено ограничение по Организации и Партнеру. Соответственно, будут сформированы ключи с возможными комбинациями организации и партнера.

В реквизит Хэш реквизит рассчитывается специальный хеш функции. Он позволяет быстро понять, существует ли уже в системе ключ с такой комбинацией значений или нет.

Структура регистров следующая:

Причем Объект РС КлючиДоступаКОбъектам имеет тип ОпределяемыйТип.ВладелецЗначенийКлючейДоступа, которые содержит в себе ссылки на все объекты, которые могут быть ограничены с помощью RLS.

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

Таким образом при проверке ограничений доступа вне зависимости от количества настроенных для конкретного проверяемого объекта видов доступа запрос всегда будет дополняться одним соединением с регистром «Ключи доступа к объектам» по проверяемому объекту и с регистром «Ключи доступа пользователей» по текущему пользователю:

Обновление ключей объектов и ключей доступа к ним выполняются регламентным заданием. А также оно может быть запущено из обработки “Обновление доступа на уровне записей”:

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

Запуск обработки выполняется по кнопке

Можно настроить обновление ключей по определенным объектам. Эта настройка выполняется по кнопке Ещё — Ручное управление… На этой форме можно выбрать конкретные справочники, документы или регистры, по которым необходимо обновить ключи, отметить их флажками, после этого запланировать обновление и запустить обработку:

Также есть возможность выводить более подробную информацию о ходе выполнения обработки

Для удобного написания и контроля текстов ограничений в комплекте поставки есть специальная обработка УправлениеДоступом:

Она позволяется в пользовательском режиме, без редактирования конфигурации формировать и проверять тексты ограничения доступа для объектов. Для этого необходимо во вкладке “Разработка ограничений доступа” необходимо выбрать список, ограничение на который нужно отредактировать:

После этого на форму загрузится текст ограничений из процедуры ПриЗаполненииОграниченияДоступа, а также шаблон ограничения в роли, а также кнопки для проверки текста вставки его в код:

При наличии ошибки в тексте ограничения и нажатии на кнопку “Проверить” появляется вкладка “(ошибки)”, в которой описаны ошибка как самого текста, так и всего внедрения механизма ограничений по записям для объекта:

Несколько конкретных примеров внедрения

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

— создать новый документ ТестовыйДокументСОграничениями

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

Примечание. В определяемый тип ВладелецЗначенийКлючейДоступаДокумент добавляются документы. Справочники нужно добавить в ВладелецЗначенийКлючейДоступаОбъект, регистры сведений — в ВладелецЗначенийКлючейДоступаНаборЗаписей, регистры расчета — в ВладелецЗначенийКлючейДоступаНаборЗаписейРегистраРасчета.

— в процедуру ПриЗаполненииСписковСОграничениемДоступа общего модуля УправлениеДоступомПереопределяемый вставить текст

— на форме документа в обработчики ПриЧтенииНаСервере и ПослеЗаписиНаСервере добавить следующий код:

— создать новые роли для чтения и добавления/изменения нового документа: ЧтениеТестовыхДокументовСОграничениями и ДобавлениеИзменениеТестовыхДокументовСОграничениями. Для них определить соответствующие права (чтение, добавление, изменение), скопировать шаблон ограничений ДляОбъекта() из роли ИзменениеУчастниковГруппДоступа и прописать код ограничения доступа для необходимых прав:

Примечание. В данном конкретном случае принимаем, что производительный режим RLS используется, поэтому ограничение для обычного режима не прописываем и в соответствующей ветке прописываем просто ИСТИНА.

• Нужно для этого документа реализовать ограничение, чтобы были доступны только те документы, в которых доступны организация и подразделение. Необходимо выполнить следующие действия:

— в модуле менеджера документа в процедуре ПриЗаполненииОграниченияДоступа прописать текст ограничения:

— в пользовательском режиме создать профили доступа с созданными ранее ролями, группы доступа и прописать в них ограничения по организациям и подразделениям и назначить их пользователям:

— создать документы и запустить задание обновления ключей доступа.

В результате получим ограниченный список документов для тестового менеджера:

под полными правами

под ограниченными правами

• Нужно реализовать ограничение, чтобы были доступны только те документы, в которых доступны организация и было доступно хотя бы одно место хранения из ТЧ Запасы.

— в модуле менеджера документа в процедуре ПриЗаполненииОграниченияДоступа прописать текст ограничения:

— добавить вид ограничения в профиль доступа, прописать в группе доступа ограничения по местам хранения, обновить ключи:

В результате под пользователем с ограниченными правами увидим только те документы, у которых доступна организация и в ТЧ Запасы хотя бы в одной строке указан Розничный склад:

• Рассмотрим пример, когда необходимо реализовать ограничение по какому-то новому реквизиту, тип которого не описан в доступных видах доступа. Реализуем такую задачу. Для этого нужно выполнить следующее:

— создать новый справочник ТестовыйРегион. Выполнить для него все те же операции, что и для самого документа ТестовыйДокументСОграничениями (роли можно создать новые или прописать в какие-то существующие, например для чтения/изменения документа. В данном примере это не принципиально. В ПриЗаполненииОграниченияДоступа прописать ограничение на само себя: ЗначениеРазрешено(Ссылка)).

— добавить ссылку и объект ТестовыйРегион в определяемые типы соотстветственно ЗначениеДоступа и ЗначениеДоступаОбъект

— в процедуру ПриЗаполненииВидовДоступа общего модуля УправлениеДоступомПереопределяемый вставить текст:

— запустить обработку ОбновлениеВспомогательныхДанных (из Инструментов разработчика) и обновить всё.

— добавить новый вид доступа в профиль доступа и определить конкретные ограничения в группе доступа:

— добавить реквизит в документ, вывести на форму, заполнить (скриншот от пользователя с полными правами):

— изменить текст ограничения в процедуре ПриЗаполненииОграниченияДоступа документа ТестовыйДокументСОграничениями, чтобы он учитывал новый реквизит:

— обновить ключи доступа.

В результате на пользователя с ограниченными правами распространяются ограничения по организациям (ООО Тестовая организация и Новые технологии ООО) и регионам (Центральный и Южный) и он получит такой список документов:

Права доступа в УПП. RLS. Общие сведения и настройка

Платформа 1С:Предприятие 8 имеет встреный механизм ограничения доступа к данным на уровне записей. Общие сведения о нем Вы можете прочитать здесь . Если кратко, то RLS позволят ограничить доступ к данным по некоторым условиям на значения полей. Например, можно ограничить доступ пользователей к документам в зависимости от значения реквизита «Организация». Некоторые пользователи будут работать с документами по организации «Управляющая компания», а остальные с организацией «Молочный завод». Как пример.

Далее в статье подробно рассмотрим шаги по настройке RLS в конфигурации «Управление производственным предприятием» для разграничения доступа пользователей по организациям.

Подготовка

Пример реализуем в демонстрационной конфигурации УПП 1.3. Создадим пользователя «Кладовщик» и добавим ему одноименную роль «Кладовщик».

Теперь приступим непосредственно к настройке прав доступа на уровне записей. Переключимся на интерфейс «Администрирование пользователе». В главном меню выберем «Доступ на уровне записей -> Параметры». Здесь отметим галкой «Ограничить доступ на уровне записей по видам объектов», а в списке объектов выберем «Организации».

Тем самым мы включили использование RLS. Теперь нужно его настроить.

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

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

В список объектов доступа для группы добавим организацию «ИЧП «Предприниматель»». Вид наследования прав оставим без изменений. Право на объект доступа установим для чтения и записи. Нажмем «ОК», настройки готовы. Мы только что настроили RLS на уровне организаций.

Что видит пользователь

Запустим программу под созданным ранее пользователем и откроем справочник «Организации». Вот так будет выглядеть список для нашего пользователя и для пользователя с полными правами:

Как мы видим, пользователь кладовщик видит только одну организацию, для которой мы открыли доступ на чтение. Тоже относится и к документам, например, поступления товаров и услуг.

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

Мы рассмотрели простейший пример настройки RLS. В следующей статье поговорим о реализации механизма RLS в конфигурации «Управление производственным предприятием» версии 1.3.

Методика подключения новых объектов к производительному методу RLS в 1С

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

Подключение новых ссылочных типов к производительному методу RLS в 1С

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

В случае если поле имеет сложный тип, то для улучшения производительности необходимо добавлять отбор RLS в реквизиты РС, и заполнять его перед записью. В таком случае текст будет иным:

2. В модуле форму объекта добавляем:

a. В событие «ПриЧтенииНаСервере» код:

b. В событие «ПослеЗаписиНаСервере» код:

3. Добавляем объект в определяемые типы «ВладелецЗначенийКлючейДоступа» и «ВладелецЗначенийКлючейДоступаДокумент» если объект – документ.

4. В ОМ «УправлениеДоступомПереопределяемый» прописываем РС в процедуре «ПриЗаполненииСписковСОграничениемДоступа

5. В шаблонах ролей добавить шаблон на чтение:

Подключение новых регистров сведений к производительному методу RLS в 1С

Данный алгоритм рассматривает РС без регистраторов

1. Добавляем РС в определяемый тип «ВладелецЗначенийКлючейДоступаНаборЗаписей»

2. В ОМ «УправлениеДоступомПереопределяемый» прописываем РС в процедуре «ПриЗаполненииСписковСОграничениемДоступа».

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

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

4. В справочник «ИдентификаторыОбъектовМетаданных» добавляем предопределенный элемент с именем «РегистрСведений» + <ИмяРС>, пример: РегистрСведенийСостояниеОбеспеченияТС

5. В шаблонах ролей добавить шаблон на чтение:

где в первом параметре шаблона «ДляРегистра» указывается нами добавленный в П4. предопределенный элемент справочника, во втором поле РС с которым связан отбор. В нашем случае это ЗаказПоставщику «Т2.Ссылка = Т.ЗаказПоставщику»

Дополнение к инструкциям по настройке RLS в 1С

Инструкции по подключению закончились, но это еще не все. Шаблоны доступа «ДляОбъекта» и «ДляРегистра» в новые роли необходимо копировать из роли «ИзменениеУчастниковГруппДоступа».

Для корректной последующей работы всего механизма необходимо обновление данных. Для этого есть три варианта: