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