Часто в работе с 1С возникает задача: нам необходимо, чтобы некоторые элементы справочника были доступны только определенным пользователям или группам, или же, наоборот, чтобы часть элементов была скрыта для всех без исключения. Например, мы хотим скрыть устаревшие позиции номенклатуры или служебные записи, которые не должны отображаться в пользовательских формах.
Для решения этой задачи мы обратимся к мощному механизму 1С — Ограничению доступа на уровне записей (RLS). RLS позволяет нам ограничивать доступ не просто ко всему объекту метаданных (например, ко всему справочнику), но и к его отдельным частям – конкретным элементам, строкам табличных частей или документам. Это ключевое отличие от обычных ролей, которые определяют общие права на использование объектов конфигурации, но не на конкретные данные внутри них.
Давайте вместе разберем, как мы можем эффективно использовать RLS для достижения нашей цели.
Рассмотрим по шагам, как мы можем настроить RLS для ограничения видимости некоторых элементов справочника для всех пользователей. Этот подход позволяет нам гибко управлять тем, что видят пользователи, без необходимости изменять код форм или запросов в каждом отчете.
Чтение, Добавление, Изменение, Удаление и т.д.). Нас интересует право Чтение, так как именно оно определяет видимость данных. Установим флажок для права "Чтение" (если он еще не установлен для всех ролей, к которым мы хотим применить ограничение) и затем нажмем кнопку "Настроить ограничение доступа" (или аналогичную кнопку рядом с полем "Чтение").
#Если &НаСервере Тогда
ГДЕ НЕ Ссылка.ПометкаУдаления
#КонецЕсли
Давайте разберем этот пример. Условие ГДЕ НЕ Ссылка.ПометкаУдаления означает, что будут выбраны только те элементы справочника, у которых реквизит ПометкаУдаления имеет значение Ложь (то есть, они не помечены на удаление). Конструкция #Если &НаСервере Тогда ... #КонецЕсли обеспечивает выполнение этого условия на сервере 1С, что является стандартной практикой для RLS.
Важно: если мы хотим ограничить доступ по другому критерию, например, по определенному реквизиту справочника (скажем, ВидНоменклатуры), то условие может быть таким:
#Если &НаСервере Тогда
ГДЕ Ссылка.ВидНоменклатуры = &ПараметрВидНоменклатуры
#КонецЕсли
В этом случае, нам потребуется использовать параметры сеанса или другие механизмы для передачи значения &ПараметрВидНоменклатуры в условие RLS. Это позволяет создавать динамические ограничения, зависящие от текущего пользователя или других условий.
Давайте углубимся в понимание RLS, чтобы использовать его максимально эффективно и осознанно.
Ограничения RLS представляют собой условия, написанные на языке запросов 1С, которые система автоматически добавляет к каждому запросу к базе данных, выполняемому от имени пользователя. Если условие выполняется для определенной записи, действие (чтение, изменение, добавление, удаление) разрешается. В противном случае, запись становится недоступной. Это означает, что скрытые данные не будут отображаться в формах, отчетах и не могут быть получены никаким запросом, что обеспечивает высокий уровень безопасности.
Важно понимать разницу. Если роли определяют общие права на использование объектов конфигурации целиком (например, право на Чтение всего справочника Номенклатура), то RLS позволяет нам ограничить доступ к *части* данных внутри этих объектов. Например, мы можем разрешить пользователю видеть справочник Номенклатура, но только те элементы, которые относятся к определенной группе или складу.
Для настройки динамических условий RLS очень удобно использовать параметры сеанса. Значения этих параметров устанавливаются при запуске сеанса пользователя (например, при входе в систему) и хранятся до его завершения. Это позволяет нам применять ограничения, которые зависят от текущего пользователя, его настроек или других условий, определенных в начале сеанса.
Если пользователю назначено несколько ролей, и каждая из этих ролей имеет настроенные ограничения доступа RLS на один и тот же объект, то эти ограничения суммируются по логическому условию "ИЛИ". То есть, если хотя бы одна роль разрешает доступ к записи, то пользователь эту запись увидит. Для упрощения управления и предотвращения нежелательных эффектов рекомендуется по возможности использовать одну роль с установленными ограничениями доступа для ограничиваемых объектов, либо тщательно продумывать логику пересечения прав.
В конфигурациях, разработанных на базе Библиотеки стандартных подсистем (БСП), часто используются стандартные шаблоны RLS, такие как #ПоЗначениям или #ПоНаборамЗначений. Эти шаблоны значительно упрощают настройку типовых ограничений доступа по различным видам доступа, например, по организациям, складам, группам контрагентов. Мы также можем добавлять собственные виды доступа и использовать их в этих шаблонах, расширяя стандартные возможности.
Механизм RLS может работать в двух режимах: стандартном и производительном. Производительный режим нацелен на повышение скорости выполнения запросов с ограничениями доступа за счет предварительного расчета прав доступа и их хранения в специальных таблицах (например, КлючиДоступа, КлючиДоступаКОбъектам, КлючиДоступаПользователей). Это делает фрагменты запросов в ролях более простыми и статичными, обеспечивая лучшую скорость работы. Однако, изменения в правах доступа вступают в силу с некоторой задержкой из-за необходимости предварительного расчета. Для использования производительного режима конфигурация должна быть на базе БСП 3.0.1 или выше, и должны быть включены соответствующие константы.
Важно понимать, что применение механизма RLS неизбежно снижает общую производительность системы, так как условие ограничения добавляется к каждому запросу к данным информационной базы. Частые причины низкой производительности RLS-запросов — неоптимальные планы выполнения запросов, часто связанные с неактуальной статистикой базы данных. Поэтому при проектировании RLS всегда следует стремиться к максимально простым и эффективным условиям.
Некорректно написанные условия RLS могут приводить к ошибкам типа "Объект не найден" для пользователей, что может быть ошибочно воспринято как "битая ссылка". В сложных системах с большим количеством пользователей и объектов поддержка RLS может быть трудоемкой, поскольку шаблоны и роли могут накладываться друг на друга и конфликтовать. Иногда требуется доработка RLS, например, для расширения типовых ограничений доступа на другие реквизиты объекта или добавления новых ограничений к типовым объектам.
Механизм RLS в основном оперирует записями (элементами, документами) целиком, а не отдельными реквизитами. Прямое ограничение чтения значения конкретного реквизита (например, скрытие поля "Оклад" в справочнике "Сотрудники") только с помощью RLS является сложной задачей и может потребовать особых подходов, таких как выборочное предоставление прав на чтение только определенных полей (Ссылка, Наименование) через метаданные, что не всегда удобно и применимо.
На форумах иногда встречается идея использовать "Пометку удаления" как способ скрыть элементы. Давайте проанализируем эту ситуацию.
Действительно, мы можем настроить параметры выбора в формах таким образом, чтобы они не показывали элементы, помеченные на удаление. Например, в параметрах выбора для поля ввода мы можем указать: НеПомеченныеНаУдаление.
Однако, это не является полноценным механизмом ограничения видимости. Вот почему:
Именно поэтому, как справедливо было отмечено в исходной теме форума, для реального ограничения видимости самих элементов справочника для всех пользователей, нам необходим полноценный механизм RLS.
Используя RLS, мы получаем мощный и гибкий инструмент для тонкой настройки прав доступа, который гарантирует, что пользователи будут видеть только ту информацию, которая им действительно необходима и разрешена.
← К списку