Как правильно разрешить доступ ко всем организациям в 1С:ЗуП 3.1 при включенном RLS?

При работе в конфигурации 1С:Зарплата и Управление Персоналом 3.1 часто возникает задача разграничения прав доступа на уровне записей (RLS). Типичная ситуация: в базе ведется учет по нескольким организациям, и доступ рядовых сотрудников ограничен их филиалами. Однако для администраторов или главных бухгалтеров требуется настроить доступ ко всем юридическим лицам сразу. Рассмотрим, какой архитектурный подход является наиболее верным и как это влияет на производительность системы.

Постановка задачи и варианты решения

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

1. Включить пользователя в каждую из трех существующих групп доступа (в каждой разрешена одна организация).
2. Создать специальную группу доступа, в которой указано, что разрешены все организации без исключений, и включить пользователя только в нее.

На первый взгляд результат кажется идентичным: и в том, и в другом случае пользователь увидит данные по всем компаниям. Однако с точки зрения внутренних механизмов платформы 1С и Библиотеки стандартных подсистем (БСП) разница между ними существенна.

Анализ механизма работы RLS в производительном режиме

Для начала проанализируем, как работает современный «производительный режим» ограничения доступа, который используется в ЗуП 3.1. В отличие от старых версий, где условия RLS при каждом запросе динамически формировали сложные условия ГДЕ, в новом режиме используются вспомогательные таблицы — Ключи доступа.

Разберем, что происходит в базе данных при выборе первого варианта (несколько групп доступа):

Когда пользователь включен в три группы, система при расчете его прав суммирует разрешенные значения по принципу ИЛИ. В служебных регистрах сведений (таких как КлючиДоступаПользователей) для этого пользователя будет создана запись, объединяющая идентификаторы ключей всех трех организаций. При выполнении любого запроса к документам или справочникам СУБД будет вынуждена выполнять соединение с таблицей ключей доступа или использовать оператор IN в SQL-запросе:

SELECT ... 
FROM Document.ПриемНаРаботу 
WHERE OrganizationID IN (ID_Организация1, ID_Организация2, ID_Организация3)

Рассмотрим ситуацию во втором варианте (одна группа с доступом «Все разрешены»):

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

Преимущества настройки «Все разрешены»

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

1. Масштабируемость системы. Представим, что завтра в вашей базе появится четвертая, пятая или десятая организация. Если вы пошли по первому пути, вам придется вручную заходить в карточку пользователя и добавлять его в новые группы доступа. В случае же настройки «Все разрешены» доступ к новым организациям появится у пользователя автоматически.
2. Минимизация ошибок учета. Рассмотрим ситуацию, когда в справочнике сотрудников или документах по ошибке не указана организация (хотя поле обычно обязательное, в результате обменов или сбоев данные могут быть повреждены). При строгом перечислении организаций в разных группах пользователь может просто «потерять» такие записи. Группа с доступом ко всем объектам позволит увидеть даже те записи, которые некорректно классифицированы.
3. Снижение нагрузки на сервер. Обновление прав доступа в 1С — ресурсоемкая операция. При изменении состава групп система инициирует фоновые задания по пересчету ключей доступа. Чем меньше групп доступа задействовано для конкретного пользователя, тем быстрее отрабатывают механизмы актуализации прав.
4. Прозрачность администрирования. Выясним, как легче контролировать права: видя одну группу «Все организации» или анализируя список из десяти групп, в каждой из которых разрешено что-то свое? Ответ очевиден. Использование специализированного профиля или группы доступа для руководителей/администраторов упрощает аудит безопасности.

Как реализовать правильную настройку (пошаговая инструкция)

Выполним настройку вместе, следуя шагам в интерфейсе программы:

1. Перейдем в раздел Администрирование — Настройки пользователей и прав — Группы доступа.
2. Нажмем кнопку Создать. В поле «Профиль» выберем тот профиль, который должен быть у пользователя (например, «Кадровик» или «Расчетчик»).
3. На вкладке Ограничения доступа найдем строку Организации.
4. В колонке «Вид доступа» установим значение Все разрешены, без исключений.
5. На вкладке Участники группы добавим нашего пользователя.

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

Влияние на динамические списки и отчеты

Посмотрим на пример работы динамического списка. Когда мы открываем список документов «Начисления зарплаты», платформа должна быстро отобразить первые 30–50 записей. При использовании множества групп доступа (Вариант 1) СУБД тратит время на проверку каждой записи по списку разрешенных организаций. На больших объемах данных (десятки тысяч сотрудников) это может приводить к заметным задержкам в отрисовке интерфейса. Вариант «Все разрешены» исключает эти проверки на уровне SQL-условия, что делает работу пользователя максимально комфортной.

Итоги анализа

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

• Максимальное быстродействие системы за счет упрощения SQL-запросов.
• Автоматический доступ к новым объектам учета.
• Простоту сопровождения и администрирования информационной базы.

Всегда старайтесь избегать «нагромождения» мелких групп доступа для одного пользователя, если их можно заменить одной более широкой настройкой.