Конструктор админ-разделов: CRUD-интерфейсы по описанию сущности
На каждом сколько-нибудь нестандартном проекте появляются данные, которым не место ни в инфоблоке, ни в highload-блоке: заявки с посадочных страниц, справочник дилеров, реестр сертификатов, журнал обмена с 1С, таблица договорных цен. Таблицу разработчик заводит за час, а потом несколько дней делает к ней административный раздел: список, фильтр, форму, валидацию, права, выгрузку. И так на каждом проекте заново.
Модуль строит рабочий раздел администрирования по описанию сущности. Описание задаётся мышкой, файлы страниц под каждый справочник не создаются, SQL писать не нужно.
ТРИ ИСТОЧНИКА ДАННЫХ
— Своя таблица. Модуль создаёт её по описанию и сам изменяет структуру, когда вы добавляете или правите поля. Перед применением показывается список предстоящих изменений; те, что приводят к потере данных, выполняются только после подтверждения.
— Highload-блок. Раздел строится поверх существующего блока: фильтр, групповое удаление и выгрузка. Структура блока не изменяется, а записи можно создавать, изменять и удалять через раздел. Множественные поля и списки хранит сам блок средствами ядра — те же значения видят компоненты сайта. Привязывает highload-блок и настраивает такой справочник — поля, считывание полей, права групп — только администратор сайта: права ядра на строки блока не раздаются вместе с правом на конструктор.
— Произвольный ORM-класс. Указывается класс-наследник Bitrix\Main\ORM\Data\DataManager из любого модуля проекта — и к его таблице появляется административный интерфейс. Привязать такой источник может только администратор сайта: доступ к чужой таблице мимо владеющего ею модуля — не то, что раздаётся вместе с правом на конструктор. Служебные таблицы портала — учётные записи, группы, права доступа, настройки, агенты — источником быть не могут вовсе. По умолчанию источник открыт только на чтение: запись включается отдельным флажком и осознанно, а записи классов ядра Битрикса остаются для просмотра в любом случае.
РАЗДЕЛ СОБИРАЕТСЯ МЫШКОЙ
Сущность, поля, вкладки формы, колонки списка, поля фильтра, пункт меню и его расположение настраиваются в административном интерфейсе. Пятнадцать типов полей: строка, многострочный текст, HTML с очисткой разметки, целое, число с точкой, да/нет, дата, дата со временем, список значений, файл, картинка, пользователь, элемент инфоблока, ссылка на другую сущность конструктора, цвет. У списка — фильтр по отмеченным полям, сортировка, постраничная навигация и групповое удаление; у формы — вкладки, обязательные поля, значения по умолчанию и проверка вводимых значений.
ПРАВА ДО УРОВНЯ ПОЛЯ
Уровень доступа к справочнику задаётся по группам пользователей, а у каждого поля есть свои уровни на чтение и на запись. Поле, закрытое на чтение, не появляется ни в списке, ни в форме, ни в фильтре, ни в выгрузке, ни в журнале изменений, ни в заголовке карточки: менеджер видит справочник поставщиков, но не видит колонку с закупочной ценой. Ссылка на запись закрытого справочника показывается номером, без подписи, а вкладка связанного справочника — только тем, у кого есть к нему доступ. Имена пользователей подписываются только тем, кому разрешено видеть пользователей, а элементы инфоблока — только из инфоблока, заданного в настройке поля, и с учётом прав на него. Права проверяются перед выполнением действия, а не только при отрисовке страницы.
ЖУРНАЛ ИЗМЕНЕНИЙ
По каждой записи видно, кто, когда и что изменил, с разницей «было / стало» по каждому полю. Журнал включается для каждого справочника отдельно, срок хранения задаётся в настройках, старые записи удаляет агент.
ВЫГРУЗКА ПО ТЕКУЩЕМУ ФИЛЬТРУ
Кнопка «Выгрузить» отдаёт XLS (SpreadsheetML) или CSV по текущему фильтру, включая другие страницы списка, до лимита export_limit из настроек модуля. Порядок строк — по первичному ключу по возрастанию, а не по текущей сортировке экрана. В выгрузку попадают поля, включённые в список и доступные пользователю на чтение.
ПЕРЕНОС СХЕМЫ МЕЖДУ ПРОЕКТАМИ
Описание справочников выгружается в файл JSON и загружается на другом сайте: сущности, поля, настройки, права по кодам групп. Переносится только описание, данные остаются на месте. При загрузке можно пропустить существующие справочники или обновить их. Создания копий под новыми кодами в интерфейсе нет. Обновление, которое удалило бы данные, импорт не применяет: такой справочник остаётся прежним, а операции перечисляются, чтобы подтвердить их в конструкторе.
ТОЧКИ РАСШИРЕНИЯ ДЛЯ РАЗРАБОТЧИКА
Шесть событий модуля с кодом сущности в параметрах: OnAdminkitBeforeSave (возврат ошибки отменяет сохранение), OnAdminkitAfterSave, OnAdminkitBeforeDelete, OnAdminkitAfterDelete, OnAdminkitBuildListQuery (правка выборки списка) и OnAdminkitRenderField (своя отрисовка ячейки). Обработчики пишутся в проекте обычным образом, файлы решения править не нужно.
ЧЕГО МОДУЛЬ НЕ ДЕЛАЕТ
Не генерирует php-файлы в проекте: весь раздел обслуживают две страницы решения, поэтому обновление модуля не конфликтует с правками на сайте. Не изменяет ядро и не подменяет штатные страницы администрирования. Не обращается к внешним сервисам, не требует ключей и подписок, не подключает сторонние скрипты. Не выполняет запросов, собранных из введённого текста: имена таблиц и колонок проходят проверку по белому списку, а данные читаются и пишутся только через ORM ядра. Не принимает в поля «файл» и «картинка» SVG, HTML и другие файлы, исполняемые браузером, — при любых настройках поля. При удалении решения таблицы созданных справочников по умолчанию сохраняются — удалить их можно отдельным флажком, увидев перед этим список таблиц и число строк в каждой.
ГРАНИЦЫ ТЕКУЩЕЙ ВЕРСИИ
Инфоблоки как источник данных не поддерживаются — у них своя система свойств, прав и редакторов. Интерфейс построен на штатных административных списках и формах Битрикса; интерфейс ui.grid не используется. Импорта данных из CSV и XLS и выдачи справочников наружу через REST в этой версии нет. Связи поддерживаются только вида «один ко многим»: поле-ссылка и вкладка связанных записей. Публичной части у решения нет — это инструмент административного раздела.
ТРЕБОВАНИЯ
— 1С-Битрикс: Управление сайтом, главный модуль 20.0.0 и новее;
— модуль «Highload-блоки» — необязателен, нужен только для источника «highload-блок»;
— модуль «Информационные блоки» — необязателен, нужен только для поля «элемент инфоблока»;
— PHP 8.2 и новее; PHP и версию главного модуля проверяет установщик;
— база данных MySQL или PostgreSQL. Приёмка решения проведена на MySQL 8 и PHP 8.2, изменение структуры справочников проверено на MySQL 8 и PostgreSQL 16.