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