← На главную

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

Для правильной настройки прав важно понимать базовые архитектурные принципы платформы «1С:Предприятие 8» и типовой подсистемы «Управление доступом» из Библиотеки стандартных подсистем (БСП), на базе которой построены такие прикладные решения, как «1С:Управление торговлей», «1С:Комплексная автоматизация» и «1С:ERP Управление предприятием».

Базовый принцип работы прав платформы: разрешительная логика

В основе системы прав платформы «1С:Предприятие» заложен разрешительный принцип. Каждое конкретное стандартное действие над объектом метаданных (например, «Чтение», «Добавление», «Изменение», «Удаление», «Просмотр» или «Интерактивное добавление») проверяется системой независимо:

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

Как объединяются условия RLS из разных ролей

Когда для одного и того же объекта метаданных и для одного и того же действия (например, «Чтение») в разных ролях заданы ограничения на уровне записей (RLS), вступает в силу строгое правило платформы:

• Условия ограничения доступа, полученные для одного действия из разных ролей, объединяются логической операцией ИЛИ.
• Условия, заданные в рамках одной роли (например, по нескольким полям или нескольким строкам условий), объединяются логической операцией И.

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

Неразрывная связь прав чтения и записи

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

При записи нового документа или сохранении изменений система проверяет возможность чтения результирующей записи. Если условия RLS на чтение не покрывают сохраняемые данные, запись будет заблокирована платформой с ошибкой нарушения прав доступа. Поэтому любая роль, предоставляющая право «Добавление» или «Изменение», в обязательном порядке должна сопровождаться правом «Чтение» на соответствующие данные.

Сложение профилей на практическом примере

Рассмотрим типовую ситуацию с документом «Заказ клиента», когда пользователю назначены два профиля групп доступа с разграничением по видам доступа (например, по складам):

• Профиль 1 (только просмотр): содержит роли только с правом «Чтение» и «Просмотр». В настройках группы доступа заданы разрешенные склады: Склад Основной, Склад 1, Склад 2.
• Профиль 2 (полная работа): содержит роли с правами «Чтение», «Добавление», «Изменение» и «Интерактивное добавление». В настройках группы доступа разрешены склады: Склад 2, Склад 4.

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

1. Право «Чтение»: действует и в Профиле 1, и в Профиле 2. Условия объединяются по правилу логического «ИЛИ». В результате пользователь может просматривать заказы по объединению всех указанных складов: Склад Основной, Склад 1, Склад 2 и Склад 4.
2. Права «Добавление» и «Изменение»: присутствуют исключительно в Профиле 2. Соответственно, создавать новые заказы и редактировать существующие пользователь может только в рамках ограничений Профиля 2 — по складам Склад 2 и Склад 4.

Итоговое поведение системы:

• Заказы по складам Склад Основной и Склад 1 доступны пользователю только для просмотра. Попытка открыть форму на редактирование или изменить реквизиты будет заблокирована.
• Заказы по складам Склад 2 и Склад 4 доступны как для просмотра, так и для создания/редактирования.

Особенности в конфигурациях на базе БСП

В современных конфигурациях 1С управление доступом на уровне пользователей реализовано через интерфейсные механизмы подсистемы БСП (справочники «Профили групп доступа», «Группы доступа», регистры сведений ключей доступа):

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