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