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