При работе в распределенных информационных базах (РИБ) администраторы и разработчики часто сталкиваются с ситуацией, когда в центральном узле данные отображаются корректно, а в периферийном — некоторые сотрудники «исчезают» из списков для пользователей с ограниченными правами. При этом под полными правами всё отображается штатно. Давайте разберем эту проблему подробно, выясним причины и найдем способы решения.
Первым делом нам необходимо понять, что в современных версиях Зарплата и управление персоналом 3.1 по умолчанию используется так называемый производительный режим RLS. В отличие от классического метода, где условия проверяются непосредственно в момент выполнения запроса к базе данных, производительный режим опирается на предварительно рассчитанные данные, которые хранятся в специальных служебных регистрах.
Если запрос в консоли запросов с использованием ключевого слова РАЗРЕШЕННЫЕ не возвращает сотрудников, это однозначно указывает на то, что система безопасности 1С блокирует доступ к этим записям. Проблема кроется не в самих данных справочника Сотрудники, а в отсутствии или некорректности записей в регистрах прав доступа в конкретной периферийной базе.
Прежде чем переходить к сложным техническим манипуляциям, давайте исключим человеческий фактор. Рассмотрим, не скрыты ли сотрудники настройками самого списка:
Разберем, какие именно таблицы отвечают за видимость объектов. В ЗУП 3.1 права рассчитываются и сохраняются в следующих регистрах:
В условиях РИБ часто возникает ситуация, когда сам объект (справочник Сотрудники) мигрировал в периферийную базу, а записи в этих регистрах — нет, либо они были рассчитаны неверно из-за разницы в настройках узлов. Выясним причину, проверив наличие записей по конкретному «невидимому» сотруднику в этих регистрах через консоль или «Функции для технического специалиста». Для наглядной проверки действующих ограничений RLS можно использовать отчет по ограничениям пользователей и группам доступа.
Важно помнить, что доступ к сотруднику в ЗУП 3.1 — это производная величина. Проанализируем цепочку зависимостей:
Если у пользователя настроено ограничение по «Группам физических лиц», то доступ к сотруднику будет закрыт, если у связанного с ним элемента справочника ФизическиеЛица не заполнена группа или на эту группу нет прав. В РИБ ссылка на физическое лицо может прийти, а данные о его принадлежности к группе доступа — потеряться при синхронизации.
Также проверим настройку «Доступ к карточке сотрудника ограничен по подразделениям». Если сотрудник переведен в новое подразделение, которое еще не «приехало» в периферийную базу или на которое у пользователя не настроены права в этой конкретной базе, объект будет скрыт.
Если мы обнаружили, что проблема вызвана некорректным расчетом RLS, выполним следующие шаги по восстановлению:
Перейдем в раздел Администрирование — Обслуживание — Управление итогами и агрегатами (или «Регламентные операции» в некоторых версиях). Нам необходимо найти пункт «Очистка и заполнение данных по правам доступа». Часто в периферийных базах расчет прав может стоять в очереди или завершиться с ошибкой. Запуск полного пересчета прав доступа обычно решает проблему «невидимок».
Если типовые средства не помогают, мы можем инициировать обновление данных для конкретного объекта программно. Рассмотрим пример кода, который можно запустить в обработке или через консоль кода для принудительного обновления ключей доступа:
// Пример принудительного обновления прав для конкретного сотрудника
СотрудникОбъект = Справочники.Сотрудники.НайтиПоРеквизиту("Код", "00001").ПолучитьОбъект();
Если СотрудникОбъект <> Неопределено Тогда
УправлениеДоступом.ОбновитьРегистрациюОбъектовДоступа(СотрудникОбъект.Ссылка);
// Вызов фонового задания обновления
ПараметрыОбновления = УправлениеДоступомСлужебный.ПараметрыОбновленияДоступа();
УправлениеДоступомСлужебный.ОбновитьДоступ(ПараметрыОбновления);
КонецЕсли;
Посмотрим на записи в журнале регистрации. Нам нужно установить отбор по пользователю и событию «Отказ в доступе». Хотя автор темы указал, что отказов по сотрудникам нет, стоит обратить внимание на отказы по объектам Справочник.ГруппыДоступаФизическихЛиц или РегистрСведений.СоставГруппУчастниковПроектов. Ограничение доступа к «родительскому» объекту или связанному регистру автоматически скрывает сотрудника из выборки РАЗРЕШЕННЫЕ.
Проанализируем ситуацию, специфичную для распределенных баз. В периферийной базе могут возникнуть «битые» ссылки в регистре КлючиДоступаПользователей. Это происходит, если идентификатор группы доступа в центральной базе изменился, а в периферийной остался старым или не обновился корректно.
Рекомендуется выполнить следующие действия в периферийной базе под полными правами:
Подводя итог, можно сказать, что «исчезновение» сотрудников в РИБ при использовании RLS в ЗУП 3.1 почти всегда связано с неактуальностью служебных регистров прав доступа. Для решения проблемы мы рекомендуем: