Почему запрос к табличной части «Группы доступа физических лиц» в ЗУП 2.5 возвращает не все данные?

При работе с разграничением прав доступа в конфигурации «Зарплата и управление персоналом 2.5» (особенно в базах с внедренными отраслевыми решениями, такими как БИТ.ФИНАНС) разработчики часто сталкиваются с ситуацией, когда стандартный запрос к табличной части справочника возвращает пустой результат или неполную выборку. Рассмотрим подробнее, почему так происходит и как правильно извлекать данные о принадлежности групп доступа пользователей к группам доступа физических лиц.

Анализ исходной проблемы и структуры запроса

Проанализируем ситуацию: разработчику необходимо отобрать все элементы справочника ГруппыДоступаФизическихЛиц, в табличной части которых указана конкретная группа пользователей. На первый взгляд, задача решается простейшим запросом к табличной части:

ВЫБРАТЬ
    ГруппыДоступаФизическихЛицбит_ГруппыПользователей.Ссылка КАК ГруппаДоступаФизЛиц,
    ГруппыДоступаФизическихЛицбит_ГруппыПользователей.Группа КАК ГруппаПользователей
ИЗ
    Справочник.ГруппыДоступаФизическихЛиц.бит_ГруппыПользователей КАК ГруппыДоступаФизическихЛицбит_ГруппыПользователей
ГДЕ
    ГруппыДоступаФизическихЛицбит_ГруппыПользователей.Группа = &Группа
УПОРЯДОЧИТЬ ПО
    ГруппыДоступаФизическихЛицбит_ГруппыПользователей.Ссылка.Наименование

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

Причина 1: Специфика хранения данных (Табличные части vs Регистры)

Разберем архитектурную особенность ЗУП 2.5 и систем на базе «БИТ». В конфигурациях на обычных формах механизм RLS (Record Level Security) — ограничение доступа на уровне записей — работает крайне медленно, если обращаться напрямую к табличным частям справочников. Для оптимизации производительности система использует «плоские» таблицы — регистры сведений.

В рассматриваемом случае данные в табличной части бит_ГруппыПользователей часто служат лишь для визуального отображения в форме элемента. Реальная же привязка прав хранится в регистре сведений ПраваДоступаПользователей (или аналогичном регистре из подсистемы БИТ). Проанализируем ситуацию: если данные были занесены в регистр программно или при переносе данных, они могут не отобразиться в табличной части справочника, если не была вызвана процедура синхронизации. И наоборот — визуально данные есть, но запрос к табличной части их не видит из-за особенностей записи объекта.

Решение: Вместо обращения к справочнику следует использовать запрос к регистру сведений. Рассмотрим пример:

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

Причина 2: Дублирование элементов и проверка ссылочной целостности

Посмотрим на ситуацию со стороны данных. Часто в базе возникают дубли справочников ГруппыПользователей или Пользователи с идентичными наименованиями. Если в параметре запроса &Группа передается ссылка на один элемент, а в табличной части справочника фактически выбрана другая ссылка (хотя текст в поле одинаковый), запрос ничего не найдет.

Проанализируем шаги для диагностики этой проблемы:

1. Используйте консоль запросов, чтобы выгрузить УникальныйИдентификатор() (GUID) для группы из параметра и для значения в «проблемной» строке табличной части.
2. Убедитесь, что тип данных в параметре совпадает с типом данных в колонке Группа.
3. Проверьте, не является ли переданная группа группой-родителем. Если структура иерархическая, оператор = не подтянет элементы, входящие в группы. В этом случае используйте В ИЕРАРХИИ.

Причина 3: Особенности префикса «бит_» и доработок

Наличие префикса бит_ в названии табличной части однозначно указывает на кастомизацию от компании «Первый Бит». В таких решениях часто реализован механизм автоматического заполнения прав. Рассмотрим, как это работает: при записи группы доступа физических лиц срабатывает подписка на событие, которая транслирует данные из табличной части в регистр. Если в какой-то момент произошел сбой или данные в регистр попали в обход формы (через ОбменДанными.Загрузка = Истина), возникнет рассинхрон.

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

Итоговые рекомендации для разработчика

Для получения гарантированно верного результата при работе с правами доступа в ЗУП 2.5 рекомендуем придерживаться следующего алгоритма:

1. Всегда проверяйте регистры прав. Основным источником истины является регистр сведений (например, ПраваДоступаПользователей или НазначениеГруппПользовательскихПрав), а не табличные части справочников.
2. Используйте универсальные отчеты. Для проверки данных попробуйте построить отчет по метаданным справочника — если универсальный отчет видит данные, а ваш запрос нет, ищите ошибку в типах параметров или условиях связи.
3. Проверяйте настройки RLS. Если ограничение прав на уровне записей в константах программы выключено, некоторые механизмы заполнения табличных частей могут игнорироваться системой.
4. Учитывайте иерархию. Всегда проверяйте, не является ли искомая группа пользователей частью другой структуры, используя условие В ИЕРАРХИИ (&Группа) вместо прямого равенства.

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