Почему в 1С:ERP после настройки RLS пропадают кадровые документы и как это исправить?

При настройке ограничений доступа на уровне записей (RLS) в крупных конфигурациях, таких как 1С:ERP 2.4 или 1С:Комплексная автоматизация, администраторы часто сталкиваются с парадоксальной ситуацией. Ограничения для справочника Сотрудники настроены верно, пользователи видят нужные им записи, однако связанные с ними документы (например, «Кадровый перевод», «Прием на работу») внезапно исчезают из списков или становятся недоступными. При этом логика прав кажется соблюденной: если сотрудник доступен, то и документ по нему должен быть виден.

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

Причина 1: Два режима работы RLS в современных конфигурациях

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

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

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

Причина 2: Использование функциональной опции как рычага управления

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

Когда мы выключаем и снова включаем ФО ОграничиватьДоступНаУровнеЗаписей, происходят следующие процессы:

• Система фиксирует масштабное изменение настроек безопасности.
• Инициируется полная очистка регистров сведений, хранящих ключи доступа.
• Запускается регламентное задание на пересчет всех прав доступа для всех объектов метаданных, включенных в систему RLS.

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

Как правильно диагностировать и исправить проблему (пошаговая инструкция)

Если вы столкнулись с выборочным исчезновением документов при работающем справочнике, выполним последовательность действий по восстановлению прав.

Шаг 1. Проверка очереди обновления прав

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

1. Перейдем в «Функции для технического специалиста» (или через «Все функции»).
2. Найдем регистр сведений ОчередьОбновленияПравДоступа.
3. Если в регистре находятся тысячи записей, которые не уменьшаются со временем, значит, регламентные задания не справляются или заблокированы.

Шаг 2. Анализ регламентных заданий

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

Шаг 3. Использование типовых инструментов БСП

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

• Отчет «Анализ локальных ключей доступа»: позволяет увидеть, какой именно ключ назначен конкретному «невидимому» документу.
• Обработка «Управление доступом»: на вкладке «Обновление доступа» можно запустить выборочное обновление прав только для определенных типов объектов (например, только для документов кадрового учета).

Шаг 4. Устранение кэширования платформы

Иногда проблема кроется в особенностях работы платформы (например, версии 8.3.15). Платформа может кэшировать контекст безопасности пользователя. Если настройки изменены, а сеанс не перезапущен, старые ограничения могут продолжать действовать. Рассмотрим алгоритм очистки:

1. Завершить все сеансы пользователя.
2. Очистить серверный кэш (папка snccntx в каталоге кластера серверов 1С).
3. Перезапустить службу агента сервера 1С.

Рекомендация по программной проверке прав

Если вы разрабатываете собственный механизм или дорабатываете типовой, полезно знать, как программно инициировать обновление прав для объекта. Посмотрим на пример вызова метода БСП:

// Пример программного обновления ключей доступа для конкретного документа
ОбъектСсылка = Документы.КадровыйПеревод.НайтиПоНомеру("001");
УправлениеДоступомСлужебный.ОбновитьКлючиДоступаОбъекта(ОбъектСсылка);

Этот метод заставит систему немедленно пересчитать права для указанного документа, не дожидаясь очереди регламентного задания.

Резюме

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