Почему в 1С:ЗУП 3.1 возникают ошибки доступа к сотрудникам при работающем RLS и как это исправить?

← На главную

Механизм ограничения прав доступа на уровне записей (RLS) в конфигурации «Зарплата и управление персоналом» редакции 3.1 является одним из самых сложных и многогранных узлов системы. Часто программисты и администраторы сталкиваются с ситуацией, когда, казалось бы, все настройки прав выполнены верно: у пользователя есть доступ к организации, есть доступ к группе физических лиц, но при попытке работы с документами система выдает ошибку нарушения прав или попросту «прячет» часть сотрудников. Рассмотрим подробнее, почему так происходит и где искать причину этой «магии».

Анализ проблемы: когда права есть, а доступа нет

Типичная ситуация разворачивается при выполнении запросов к справочнику Сотрудники. Проанализируем пример кода, который часто встречается в типовых механизмах или доработках:


Запрос.Текст =
    "ВЫБРАТЬ
    |    Сотрудники.Ссылка КАК Сотрудник,
    |    Сотрудники.ФизическоеЛицо КАК ФизическоеЛицо
    |ПОМЕСТИТЬ ВТФизическиеЛица
    |ИЗ
    |    Справочник.Сотрудники КАК Сотрудники
    |ГДЕ
    |    Сотрудники.ФизическоеЛицо В(&СписокФизическихЛиц)
    |    И Сотрудники.ГоловнаяОрганизация = &ГоловнаяОрганизация";
Запрос.Выполнить();

На первый взгляд, запрос корректен. Однако под пользователем с ограниченными правами он может вернуть меньше записей, чем под пользователем с полными правами, или вовсе вызвать исключение «У пользователя недостаточно прав на исполнение операции над базой данных». Выясним причину: в данном запросе отсутствует ключевое слово РАЗРЕШЕННЫЕ. В типовых конфигурациях это часто делается намеренно, чтобы программа не «проглатывала» отсутствие прав, а сигнализировала о проблеме в данных. Если при отключении RLS по организациям проблема исчезает, значит, корень зла кроется именно в механизме связи сотрудника и организации.

Секретный механизм: Регистр «Организации, в которых работали сотрудники»

Разберем, как именно 1С:ЗУП 3.1 проверяет права доступа. Для повышения производительности система не вычисляет права «на лету», анализируя каждый раз кадровые приказы о приеме или переводе. Вместо этого используется специализированный «производительный режим» RLS, который опирается на вспомогательные (оптимизационные) данные.

Ключевым объектом здесь является регистр сведений ОрганизацииВКоторыхРаботалиСотрудники. Это плоский список, в котором система хранит жесткую связку: Сотрудник — Организация. Именно по этому регистру RLS фильтрует выборку из справочника Сотрудники. Если записи по конкретному человеку в этом регистре нет, то для механизма защиты этот сотрудник «ничей», и доступ к нему будет заблокирован, даже если в самой карточке сотрудника поле ГоловнаяОрганизация заполнено верно.

Почему данные в регистре могут отсутствовать?

Проанализируем основные причины рассинхронизации данных в служебных регистрах:

Программная запись объектов: Если сотрудники или кадровые документы создавались программно с установленным признаком ОбменДанными.Загрузка = Истина, подписки на события, отвечающие за обновление регистра ОрганизацииВКоторыхРаботалиСотрудники, могли не сработать.
Ошибки миграции: При переносе данных из предыдущих версий (например, ЗУП 2.5) или из сторонних систем этот регистр часто остается незаполненным, так как он специфичен для архитектуры 3.1.
Сбои регламентных заданий: Пересчет прав доступа часто выполняется в фоновом режиме. Если фоновое задание было прервано или завершилось с критической ошибкой, база остается в состоянии «частичного доступа».

Пошаговое решение проблемы

Рассмотрим методы восстановления корректной работы RLS без внесения изменений в конфигурацию:

Способ 1: Использование стандартных инструментов обслуживания

В типовых решениях на базе БСП (Библиотеки стандартных подсистем) предусмотрены механизмы для исправления подобных ситуаций. Разберем по шагам:

Перейдем в раздел Администрирование — Обслуживание.
Выберем пункт Управление доступом.
Нажмем кнопку Обновить (в некоторых версиях — «Обновить параметры доступа»). Это инициирует полный пересчет всех служебных регистров прав.
Также проверим состояние регламентного задания ОбновлениеДанныхДляОграниченияДоступа. Оно должно выполняться успешно и без ошибок в журнале регистрации.

Способ 2: Принудительная перезапись данных

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

Найдем проблемного сотрудника в списке.
Откроем карточку сотрудника и внесем любое несущественное изменение (например, добавим пробел в комментарий) или просто нажмем Записать и закрыть.
В этот момент сработает подписка на событие, которая должна создать запись в регистре ОрганизацииВКоторыхРаботалиСотрудники.
Если перезапись сотрудника не помогла, следует проделать то же самое с кадровым документом (Прием на работу), так как именно он является первичным источником связи с организацией.

Способ 3: Переключение режимов RLS

Выясним причину поведения системы через настройки производительности. В разделе Настройки — Настройки пользователей и прав можно найти управление режимом работы RLS:

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

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

Использование «РАЗРЕШЕННЫЕ» в запросах

Проанализируем ситуацию с точки зрения разработки. Если вы пишете собственный отчет или обработку, добавление РАЗРЕШЕННЫЕ в текст запроса:

"ВЫБРАТЬ РАЗРЕШЕННЫЕ ..."

позволит избежать падения системы с ошибкой. Программа просто исключит из выборки те записи, на которые у пользователя нет прав. Однако помните, что в учетных механизмах (расчет зарплаты, налогов) это может привести к фатальным последствиям: расчетчик может рассчитать зарплату по части сотрудников, даже не подозревая, что часть данных была скрыта фильтром RLS. Именно поэтому в типовых процедурах проведения документов РАЗРЕШЕННЫЕ практически не используется — система обязана видеть всё, что положено по закону, либо честно сообщать об ошибке доступа.

Таким образом, «магия RLS» в ЗУП 3.1 чаще всего объясняется техническим несоответствием данных в основных справочниках и оптимизационных регистрах сведений. Своевременное обслуживание базы и понимание работы механизмов БСП позволяют быстро локализовать и устранить подобные ошибки.