При работе с распределенными информационными базами (РИБ) системные администраторы и программисты часто сталкиваются с ситуацией, когда в центральном узле права доступа работают корректно, а в периферийном узле пользователь с теми же настройками видит пустые списки документов (например, заказов покупателей). Эта проблема особенно характерна для конфигураций на базе Библиотеки стандартных подсистем (БСП), таких как 1С:Управление нашей фирмой (УНФ), 1С:ERP или 1С:Комплексная автоматизация, где используется производительный режим RLS.
В данной статье мы разберем, почему возникает эта ошибка, как работают внутренние механизмы ограничения доступа в РИБ и каким способом можно принудительно заставить систему пересчитать права доступа, чтобы данные снова стали видимыми.
Рассмотрим типовой сценарий. В центральной базе пользователю назначены группы доступа с ограничением по организации. Все работает штатно: пользователь видит документы только «своей» организации. После синхронизации данных с филиалом (периферийным узлом) тот же пользователь заходит в базу под своими учетными данными, но списки документов оказываются пустыми, хотя сами документы физически присутствуют в узле.
Первое, что часто пробуют сделать специалисты — это исключить пользователя из группы доступа и добавить его обратно. Как показывает практика, это дает лишь временный эффект. Проанализируем, почему это происходит: при изменении состава групп доступа БСП инициирует локальный пересчет прав для конкретного пользователя. Однако при очередном обмене данными из центра могут прийти обновленные служебные регистры, которые снова «затрут» локальные настройки, а автоматический фоновый пересчет в узле может не запуститься.
Чтобы понять решение, нам нужно разобраться, как устроено ограничение доступа на уровне записей (RLS) в БСП. В современном «производительном» режиме система не высчитывает права каждый раз при выполнении запроса к базе данных. Вместо этого используются специальные вспомогательные таблицы (регистры сведений):
В РИБ эти данные должны передаваться или пересчитываться локально. Если в плане обмена исключены служебные регистры или если в периферийном узле не работают регламентные задания, «связи» между пользователем и объектами обрываются. Система «считает», что у пользователя нет доступа ни к одному ключу, и скрывает все записи.
Иногда программисты пытаются вызвать методы обновления регистров из кода. Рассмотрим пример кода, который часто пробуют применять, но который в случае с глубоким сбоем RLS может оказаться недостаточно эффективным:
// Попытка принудительного обновления данных в регистрах БСП
РегистрыСведений.ТаблицыГруппДоступа.ОбновитьДанныеРегистра();
РегистрыСведений.ЗначенияГруппДоступа.ОбновитьДанныеРегистра();
Эти методы обновляют только часть информации. Проблема в том, что RLS в БСП задействует гораздо больше механизмов, включая параметры сеанса и кэшированные данные в оперативной памяти. Если «сломана» сама логика соответствия ключей доступа в периферийном узле, обычного обновления двух регистров будет недостаточно.
Самым эффективным и полным способом восстановления работоспособности прав доступа в узле РИБ является запуск информационной базы со специальным параметром командной строки. Этот метод заставляет систему выполнить все процедуры обновления, предусмотренные при переходе на новую версию конфигурации, включая полную очистку и пересчет всех таблиц RLS.
Разберем по шагам, как это сделать:
/С ЗапуститьОбновлениеИнформационнойБазы
Важно: Обратите внимание, что буква /C должна быть латинской, а после нее через пробел идет текст команды. После успешного входа в базу и завершения всех фоновых процедур обновления, этот параметр из настроек запуска следует удалить, иначе при каждом входе система будет пытаться инициировать обновление заново.
Проанализируем ситуацию: параметр ЗапуститьОбновлениеИнформационнойБазы инициирует выполнение процедур из общего модуля ОбновлениеИнформационнойБазы. В рамках этого процесса БСП вызывает обработчики обновления, которые:
ТаблицыГруппДоступа и ГруппыЗначенийДоступа.Это «лечит» даже те ситуации, когда в узле РИБ возникла рассинхронизация метаданных ролей и фактических записей в регистрах прав.
Чтобы проблема не повторялась после очередного обмена данными, рекомендуем проверить следующие моменты:
1. Работа регламентных заданий. В файловых базах (которые часто используются на торговых точках) регламентные задания не выполняются сами по себе, если не открыт специальный сеанс или не настроен автоматический запуск. Проверьте, работает ли задание «Заполнение данных для ограничения доступа». Если оно висит в состоянии «Ошибка» или «Не определено», права не будут обновляться.
2. Панель обслуживания БСП. Зайдите в раздел Администрирование — Обслуживание — Управление доступом. Проверьте, нет ли там предупреждений о необходимости обновления данных доступа. В некоторых версиях БСП там доступна кнопка «Обновить», которая позволяет запустить пересчет без перезагрузки всей базы с параметрами.
3. Профили групп доступа. Убедитесь, что в периферийный узел мигрировали все необходимые профили и роли. Если в центре была создана новая роль и добавлена в профиль, а конфигурация в узле еще не обновилась (динамическое обновление или задержка в обмене), RLS может заблокировать доступ, так как не найдет описание новой роли в структуре прав.
Таким образом, использование параметра /C ЗапуститьОбновлениеИнформационнойБазы является наиболее надежным способом «реанимации» прав доступа в распределенных базах на платформе 1С 8.3.