При обслуживании, доработке или обновлении конфигураций на платформе 1С:Предприятие 8.3 разработчики часто сталкиваются с системными проверками безопасности, встроенными в Библиотеку стандартных подсистем (БСП). Одна из таких распространенных и на первый взгляд неочевидных ошибок возникает при запуске стандартной обработки «Обновление вспомогательных данных». Система аварийно завершает работу, выдавая следующее сообщение:
При проверке ролей для пользователей приложения найдены ошибки: Роль "ИмяРоли" содержит право Изменение неразделенного объекта ПланВидовХарактеристик.РазделыДатЗапретаИзменения. ВызватьИсключение ЗаголовокОшибки + ТекстОшибки;
В этой статье мы подробно разберем, что такое неразделенный объект в архитектуре 1С, почему платформа и БСП накладывают жесткие ограничения на работу с ним, а также рассмотрим три практических способа устранения этой ошибки.
Для того чтобы понять природу этой ошибки, нам необходимо обратиться к архитектуре облачных решений (SaaS) и технологии 1С:Fresh. Платформа 1С:Предприятие поддерживает механизм разделения данных. Этот механизм позволяет запускать одну информационную базу для работы сотен и тысяч независимых организаций (абонентов). При этом физически база данных одна, но логически она разделена на изолированные области.
В такой архитектуре все объекты метаданных делятся на две принципиальные группы:
ОбластьДанныхОсновныеДанные). Пользователи конкретного абонента имеют доступ только к тем записям, у которых значение разделителя совпадает с их областью данных. Они создают свои собственные документы, справочники контрагентов и номенклатуры, не видя данных других организаций.ПланВидовХарактеристик.РазделыДатЗапретаИзменения. Эти данные хранятся в единственном экземпляре и используются всеми областями данных одновременно.Проанализируем логику работы БСП. Механизм контроля прав настроен таким образом, чтобы исключить ситуацию, при которой обычный пользователь из своей изолированной области данных сможет непреднамеренно или злонамеренно изменить общие (неразделенные) данные всей системы.
Если бы условный бухгалтер в своей области данных мог отредактировать или пометить на удаление элемент общего плана видов характеристик РазделыДатЗапретаИзменения, это изменение мгновенно отразилось бы на всех остальных независимых организациях, работающих в этой же базе. Это привело бы к нарушению целостности данных и сбоям в работе сотен пользователей.
Именно поэтому при обновлении вспомогательных данных БСП запускает жесткую валидацию ролей. Если обнаруживается, что кастомная (созданная разработчиком) роль, назначенная обычным пользователям, имеет права «Изменение», «Добавление» или «Удаление» для любого неразделенного объекта, система блокирует применение изменений и выбрасывает исключение.
Выяснив первопричину, перейдем к пошаговому рассмотрению способов решения этой проблемы.
В подавляющем большинстве случаев обычным пользователям (например, менеджерам по продажам или кладовщикам), которым назначается роль доработкаПроизводство, абсолютно не требуется изменять структуру плана видов характеристик РазделыДатЗапретаИзменения. Им достаточно иметь возможность просто считывать эти данные для корректного проведения документов.
Выполним корректировку прав по шагам:
доработкаПроизводство).ПланВидовХарактеристик.РазделыДатЗапретаИзменения (или к тому объекту, который фигурирует в тексте вашей ошибки).Обновление вспомогательных данных.Этот способ является самым правильным и безопасным с точки зрения архитектуры 1С, так как он полностью закрывает потенциальную брешь в безопасности прав доступа.
Рассмотрим другую ситуацию: создаваемая вами роль является административной. То есть пользователи с этой ролью действительно должны иметь возможность настраивать и изменять общие системные классификаторы и настройки для всей базы данных в целом.
Для таких ролей в БСП предусмотрен специальный механизм регистрации. Нам необходимо явно «объяснить» системе, что данная роль предназначена исключительно для администраторов всей системы (неразделенных пользователей).
Выполним регистрацию роли программно:
ПользователиПереопределяемый.ПриОпределенииНазначенияРолей.Пример кода для добавления нашей роли в список системных:
Процедура ПриОпределенииНазначенияРолей(НазначениеРолей) Экспорт
// Регистрируем нашу роль как предназначенную только для администраторов системы
НазначениеРолей.ТолькоДляПользователейСистемы.Добавить("доработкаПроизводство");
КонецПроцедуры
Важное примечание: если вы ведете разработку в типовой конфигурации, находящейся на поддержке, крайне не рекомендуется изменять типовой модуль напрямую. Вместо этого заимствуйте общий модуль ПользователиПереопределяемый в свое расширение конфигурации и расширьте процедуру ПриОпределенииНазначенияРолей с помощью аннотации &После.
Пример реализации в расширении:
&После("ПриОпределенииНазначенияРолей")
Процедура Расш_ПриОпределенииНазначенияРолей(НазначениеРолей)
НазначениеРолей.ТолькоДляПользователейСистемы.Добавить("доработкаПроизводство");
КонецПроцедуры
Бывают ситуации, когда обновление конфигурации или обработку вспомогательных данных нужно выполнить экстренно, а времени на полноценную переработку ролей и обновление расширений прямо сейчас нет. В этом случае мы можем временно отключить валидацию ролей в самой обработке.
Проанализируем порядок действий в режиме «1С:Предприятие»:
Система успешно выполнит обновление вспомогательных данных, проигнорировав несоответствие прав в роли доработкаПроизводство. Однако помните, что этот метод является лишь временной мерой. При следующем автоматическом обновлении или реструктуризации базы данных проверка может запуститься вновь, поэтому настоятельно рекомендуется при первой возможности исправить права роли по первому или второму способу.
Мы полностью разобрали понятие неразделенных объектов в 1С, выяснили причины возникновения блокирующей ошибки контроля ролей в БСП и рассмотрели все возможные варианты ее устранения. Выбор конкретного метода зависит от архитектурных задач вашего проекта и от того, действительно ли пользователям роли необходимы права на запись общих системных данных.