Как настроить ограничение доступа (RLS) к справочнику «Внешние обработки» в 1С:УПП 1.3

Настройка разграничения доступа на уровне записей (RLS) в конфигурации «Управление производственным предприятием 1.3» — задача не самая тривиальная. Часто системные администраторы и программисты сталкиваются с тем, что стандартная логика системы работает по принципу «Разрешено только то, что явно указано». Это создает массу неудобств, когда нужно закрыть всего одну папку в справочнике ВнешниеОбработки, оставив остальные доступными. В этой статье мы подробно разберем, как работает этот механизм, и как реализовать задачу «от обратного».

Разбираем базовую настройку типового механизма RLS

Для начала рассмотрим, как активировать стандартный механизм ограничения прав в УПП 1.3. Без выполнения этих шагов никакие записи в регистрах не будут иметь силы. Пройдем по этапам настройки интерфейса:

1. Перейдем в меню Сервис — Настройка программы. На закладке Ограничение доступа убедимся, что установлены флаги «Использовать ограничения на уровне записей».
2. В списке видов объектов доступа найдем «Внешние обработки» и установим соответствующую галочку. Это сигнализирует системе, что теперь при обращении к справочнику ВнешниеОбработки будет выполняться проверка прав.
3. Создадим Группу пользователей (или выберем существующую). В форме группы на закладке «Объекты доступа» выберем вид объекта «Внешние обработки».
4. Добавим в список те элементы или папки справочника, к которым мы хотим разрешить доступ.

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

Проблема «белого списка» и наследования прав

Проанализируем ситуацию, описанную пользователями: когда мы включаем RLS для внешних обработок, все элементы, не попавшие в список разрешенных, автоматически становятся невидимыми. Это классическая логика «белого списка».

Рассмотрим пример: у нас есть папка «Общие» и папка «Секретные». Если мы разрешим группе доступ только к папке «Общие», то при создании новой папки «Бухгалтерия» пользователи ее не увидят, пока администратор вручную не добавит ее в настройки. Чтобы минимизировать ручной труд, проанализируем поле «Вид наследования» в настройках прав:

• Только для текущего объекта: Доступ дается только на выбранную папку или элемент.
• Распространять на подчиненные: Доступ автоматически распространяется на все элементы внутри папки и на вложенные папки.

Использование флага Распространять на подчиненные позволяет частично решить проблему новых отчетов — достаточно положить их в уже «разрешенную» папку.

Почему настройки могут не работать? Проверка полных прав и ролей

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

1. Роль «Полные права»: Если у пользователя назначена эта роль, платформа полностью игнорирует любые запросы RLS. Пользователь с полными правами всегда видит всё. Проверьте список ролей пользователя в Конфигураторе.
2. Роль «Пользователь»: В УПП 1.3 эта роль является базовой. В ней уже прописаны типовые шаблоны RLS. Если вы создаете свою роль с ограничениями, они будут суммироваться с ограничениями роли «Пользователь» по правилу «ИЛИ» (если хоть одна роль разрешает чтение, объект будет виден).
3. Группа доступа в самом справочнике: В справочнике ВнешниеОбработки есть реквизит ГруппаДоступаКОбъекту. Если он не заполнен, типовой механизм может блокировать доступ, так как не может сопоставить элемент с правилами в регистре.

Реализация задачи «Запретить только определенную папку» через кастомный RLS

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

Найдем в Конфигураторе роль, отвечающую за чтение справочника ВнешниеОбработки (обычно это Пользователь или специализированная роль). Нажмем правой кнопкой на справочник в списке объектов роли и выберем «Установить ограничение доступа к данным». Нам нужно изменить текст запроса для права Чтение.

Вместо стандартного вызова шаблона #ВнешниеОбработки("Чтение"), мы можем написать прямой запрос. Рассмотрим пример кода:

ГДЕ НЕ Ссылка В ИЕРАРХИИ (
    ВЫБРАТЬ
        Рег.ОбъектДоступа
    ИЗ
        РегистрСведений.НастройкиПравДоступаПользователей КАК Рег
    ГДЕ
        Рег.Пользователь В (&ГруппыТекущегоПользователя)
        И Рег.ЗапретитьДоступ = ИСТИНА
)

Однако более простым и надежным способом будет использование предопределенного значения или конкретной ссылки. Рассмотрим ситуацию, когда нам нужно скрыть папку с конкретным кодом или наименованием:

ВнешниеОбработки ГДЕ НЕ (ВнешниеОбработки.Родитель.Наименование = "Плановый" 
    ИЛИ ВнешниеОбработки.Наименование = "Плановый")

Внимание: Использование жестко прописанных строк в RLS — плохая практика. Правильнее будет создать в справочнике ВнешниеОбработки дополнительный реквизит типа Булево (например, Секретно) и прописать условие:

ВнешниеОбработки ГДЕ ВнешниеОбработки.Секретно = ЛОЖЬ

Затем для специальной роли «Доступ к плановым обработкам» ограничение можно либо снять совсем, либо прописать разрешающее условие. Таким образом, все новые обработки по умолчанию будут иметь флаг Секретно = ЛОЖЬ и будут видны всем, а «плановые» — только обладателям специальной роли. Для массового назначения или изменения ролей у пользователей подойдёт обработка для быстрого изменения состава ролей в УПП 1.3.

Обновление параметров сеанса и кэша

После того как вы изменили программный код RLS или настройки в регистре, пользователь может продолжать видеть старые данные. Проанализируем, почему это происходит. Платформа 1С кэширует права доступа в рамках текущего сеанса пользователя.

Чтобы изменения вступили в силу, необходимо:

1. Заставить пользователя завершить работу и зайти в программу заново.
2. В некоторых случаях требуется очистка локального кэша метаданных (папка %AppData%\1C\1Cv8).
3. Если используется серверный вариант, может потребоваться перезапуск регламентного задания по обновлению прав доступа, если таковое настроено в вашей конфигурации.

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

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