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