Разработка в расширениях конфигурации на платформе «1С:Предприятие» — это удобный инструмент, позволяющий кастомизировать систему, не снимая типовое решение с поддержки. Однако программисты часто сталкиваются с неочевидным поведением системы. Одной из классических проблем является ситуация, когда новые объекты (справочники, документы, обработки), добавленные в расширение, наотрез отказываются появляться в меню «Все функции» (в современных версиях платформы — «Функции для технического специалиста»), даже если запуск базы производится под пользователем с полными правами.
В этой статье мы подробно разберем, почему возникает эта проблема, как устроена система безопасности платформы при работе с расширениями, а также проанализируем архитектурные риски добавления новых метаданных в расширения.
Для начала проанализируем поведение платформы «1С:Предприятие» при работе с правами доступа в расширениях. Логика работы системы безопасности зависит от наличия ролей внутри самого расширения. Здесь действует важное правило, которое делит работу расширения на два режима:
Все функции.ПолныеПрава из основной конфигурации «не знает» о существовании новых объектов в расширении, администратор мгновенно теряет к ним доступ, и они исчезают из меню Все функции.Именно поэтому, когда автор темы добавил роль ПолныеПрава в расширение и явно отметил галочками права на новые объекты, они снова появились в интерфейсе.
Понимая неудобство ручного заимствования ролей для каждого расширения, фирма «1С» начиная с версии платформы 8.3.14 добавила специализированный механизм — Основные роли расширения. Рассмотрим, как это работает и как настроить систему правильно.
Разберем по шагам процесс настройки:
Использовать основные роли для всех пользователей и установим его в значение Истина.ИмяРасширения_ОсновнаяРоль), которая неявно назначается всем пользователям базы данных.Благодаря этому флагу права из основных ролей расширения будут применяться ко всем пользователям автоматически, что избавит вас от необходимости переносить роль ПолныеПрава в расширение и раздавать права вручную.
Если ваша конфигурация построена на базе БСП (а это практически все современные типовые решения), механизм интеграции ролей выглядит следующим образом:
ПолныеПрава) настраивать профили в режиме предприятия не требуется, однако в самом расширении роль ПолныеПрава все равно должна быть заимствована и содержать явные разрешения (чтение, просмотр, редактирование) на новые объекты расширения, если не используется механизм основных ролей версии 8.3.14.Некоторые разработчики сознательно отказываются от использования ролей внутри расширения, чтобы не усложнять поддержку прав доступа. Вместо этого они используют программные ограничения видимости элементов интерфейса и проверку прав на уровне кода («RLS на коленке»).
Рассмотрим пример реализации такой проверки. Создадим в расширении собственный регистр сведений ДоступПользователейРасширения, в котором будем хранить настройки разрешений, и напишем функцию проверки доступа:
Функция ДоступКОбъектуРазрешен(ИмяПользователя, ИмяОбъекта) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| НастройкиДоступа.Разрешено КАК Разрешено
|ИЗ
| РегистрСведений.ДоступПользователейРасширения КАК НастройкиДоступа
|ГДЕ
| НастройкиДоступа.Пользователь = &Пользователь
| И НастройкиДоступа.ОбъектМетаданных = &ОбъектМетаданных";
Запрос.УстановитьПараметр("Пользователь", ИмяПользователя);
Запрос.УстановитьПараметр("ОбъектМетаданных", ИмяОбъекта);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выполнить();
Выборка.Следующая();
Возврат Выборка.Разрешено;
КонецЕсли;
Возврат Ложь;
КонецФункции
Такой подход позволяет гибко управлять видимостью элементов на формах программным путем в модулях модифицируемых форм через обработчик ПриСозданииНаСервере.
Опытные разработчики часто предостерегают от создания новых реквизитов и физических объектов непосредственно в расширениях. Рассмотрим подробнее две ключевые проблемы, с которыми вы можете столкнуться.
Когда мы заимствуем стандартный объект (например, справочник Номенклатура) и добавляем к нему новый реквизит в расширении, платформа не добавляет новую колонку в основную таблицу СУБД _ReferenceXX. Вместо этого СУБД создает отдельную физическую таблицу для расширения.
При каждом обращении к этому справочнику (при формировании динамических списков, отчетов или программном чтении) платформа вынуждена выполнять операцию соединения таблиц (LEFT JOIN) основной конфигурации и расширения на уровне базы данных. При росте объема данных (сотни тысяч и миллионы записей) это приводит к колоссальному снижению производительности и высокой нагрузке на сервер СУБД.
Данные, хранящиеся в созданных внутри расширения объектах или добавленных реквизитах, жестко привязаны к самому расширению на уровне СУБД. Проанализируем опасную ситуацию: если в процессе обновления базы данных, сбоя или ошибочных действий администратора расширение будет удалено, отключено, либо у него изменится уникальный идентификатор (UID) или имя — все данные в этих реквизитах и объектах будут навсегда удалены из СУБД. Восстановить их в таком случае удастся только из резервной копии базы данных.
Именно поэтому в сообществе 1С пользуется популярностью компромиссный подход:
Также важно помнить, что платформа накладывает жесткие ограничения на типы данных. В расширениях принципиально нельзя создавать следующие объекты:
Понимание этих архитектурных особенностей позволит вам проектировать надежные и быстродействующие системы, избегая скрытых ловушек при работе с расширениями в платформе «1С:Предприниматель».