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