При работе с современными конфигурациями на базе Библиотеки стандартных подсистем (БСП), особенно в режиме разделения данных (SaaS/Fresh), разработчики часто сталкиваются с жесткими проверками безопасности. Одна из самых распространенных и неприятных проблем — ошибка в процедуре ПриОпределенииНазначенияРолей, которая возникает при попытке обновить вспомогательные данные. Система сообщает, что конкретная роль содержит право на добавление или изменение неразделенного объекта, например, такого как Справочник.ПроизводственныеКалендари. Разберем детально, почему это происходит и как правильно решить эту задачу.
Для начала проанализируем ситуацию с точки зрения архитектуры 1С. В облачных решениях данные делятся на два типа: разделенные (данные конкретного клиента или организации) и неразделенные (общие для всех пользователей системы, такие как классификаторы, валюты или производственные календари). За управление этим механизмом отвечает общий реквизит, обычно называемый ОбластьДанныхОсновныеДанные.
Проанализируем логику работы БСП: функция ПриОпределенииНазначенияРолей предназначена для того, чтобы система понимала, для какой категории пользователей создана та или иная роль. Существуют три основные категории:
Ошибка «Роль содержит право Добавление неразделенного объекта» — это защитный механизм. БСП считает, что если роль предназначена для обычного пользователя области данных, то она не должна иметь прав на изменение объектов, которые являются общими для всей базы. Если бы пользователь одной фирмы смог изменить Справочник.ПроизводственныеКалендари, это отразилось бы на всех остальных фирмах в этой же информационной базе, что недопустимо в модели SaaS.
Рассмотрим подробнее объект Справочник.ПроизводственныеКалендари. В типовых решениях (ERP, ЗУП, КА) у этого справочника в составе общего реквизита разделения данных часто снята галочка «Автоматически». Это означает, что справочник является общим (неразделенным). Если ваша самописная роль или доработанная типовая роль дает право на Добавление, Изменение или Удаление этого справочника, БСП заблокирует обновление вспомогательных данных, считая это дырой в безопасности.
Как показывает практика практикующих разработчиков, иногда самым быстрым способом является полный пересмотр состава ролей. Если роль была создана некорректно или дублирует функции других ролей, рассмотрим вариант её удаления. Посмотрим на алгоритм действий:
Этот метод радикален, но эффективен, когда роль «перегружена» лишними правами, которые ей не принадлежат по логике бизнес-процесса.
Если роль необходима и должна содержать права на редактирование общих данных, мы должны явно сообщить об этом системе. Разберем, как это сделать программно. Нам потребуется внести изменения в общий модуль УправлениеДоступомПереопределяемый, в процедуру ПриОпределенииНазначенияРолей.
Рассмотрим пример кода, который позволяет классифицировать роль как административную, снимая тем самым ограничение на доступ к неразделенным данным:
Процедура ПриОпределенииНазначенияРолей(НазначениеРолей) Экспорт
// Указываем, что наша роль предназначена только для администраторов системы
НоваяСтрока = НазначениеРолей.Добавить();
НоваяСтрока.Роль = Метаданные.Роли.МояСпециальнаяАдминистративнаяРоль;
НоваяСтрока.Назначение = "ДляАдминистраторовСистемы";
КонецПроцедуры
После внесения этих изменений система поймет, что данная роль не будет выдаваться обычным пользователям областей данных, и проверка на «неразделенность» объекта Справочник.ПроизводственныеКалендари будет успешно пройдена.
Иногда ошибка возникает из-за использования устаревших внешних обработок для обновления вспомогательных данных. Вместо использования сторонних инструментов, рассмотрим стандартный механизм платформы и БСП. Для корректного формирования кэша идентификаторов и вспомогательных данных рекомендуется запускать базу из командной строки с определенными параметрами.
Посмотрим на пример параметров запуска:
1cv8.exe ENTERPRISE /F "ПутьКБазе" /N "Админ" /P "Пароль" /C "ЗапуститьОбновлениеИнформационнойБазы" /UpdateConfigДополнительныеПараметры
Использование параметра /UpdateConfigДополнительныеПараметры инициирует полный цикл обновления метаданных и вспомогательных таблиц БСП, что зачастую помогает избежать ошибок, возникающих при частичном или ручном обновлении через обработки.
Важно понимать, что наличие RLS (Record Level Security) не отменяет вышеописанную проверку. Даже если вы настроили RLS так, что пользователь видит только свои записи, сама попытка дать право на «Добавление» в таблицу, которая помечена в метаданных как общая, будет пресечена на этапе инициализации системы.
Поэтому проанализируем архитектуру вашего решения еще раз: если бизнес-логика действительно требует, чтобы каждый пользователь (организация) имел свой собственный производственный календарь, то правильным решением будет не обход ошибки в коде, а изменение состава общего реквизита разделения. Нужно включить справочник в состав ОбластьДанныхОсновныеДанные, установив использование в значение «Использовать». Однако помните, что это повлечет за собой необходимость пересмотра всех запросов и отчетов, использующих этот справочник.
Таким образом, для решения проблемы мы рекомендуем сначала определить, является ли доступ к объекту в этой роли избыточным. Если нет — используйте программное назначение роли администратору через УправлениеДоступомПереопределяемый. Это обеспечит чистоту кода и стабильную работу системы в будущем.