Admin Section Builder

What this solution does

On non-standard projects, data often appears that fits neither in information blocks nor in highload blocks: landing page submissions, dealer directories, certificate registries, 1C exchange logs, or contract price tables. A developer can create the table in an hour, but building the administrative section—list, filters, forms, validation, permissions, and export—can take several days. This cycle repeats on every project.

The module generates a functional administrative section based on an entity description. The description is created via a graphical interface; no separate page files are generated, and writing SQL code is unnecessary.

THREE DATA SOURCES

— Own table. The module creates the table based on the description and automatically modifies its structure when fields are added or edited. Before applying changes, the system displays a list of pending modifications. Operations that result in data loss are executed only after explicit user confirmation.

The module enables the creation of administrative sections based on Highload blocks and arbitrary ORM classes.

For Highload blocks, the interface is built on top of the existing structure. Features include filtering, bulk deletion, and data export. The block structure remains unchanged, while records can be created, edited, and deleted through the new section. Multiple fields and lists are stored using core mechanisms, ensuring that site components see the same values. Binding the block, configuring fields, reading fields, and managing group rights are available exclusively to the site administrator. Core permissions for block rows are not automatically granted when rights to use the constructor are issued.

For arbitrary ORM classes inheriting from Bitrix\Main\ORM\Data\DataManager in any project module, an administrative interface is automatically generated. Binding such data sources is also restricted to the site administrator. Access to external tables outside the context of the owning module is not provided. Portal service tables, including user accounts, groups, access rights, settings, and agents, cannot be used as sources. By default, access to data is read-only. The ability to write records is enabled via a separate flag and requires conscious action. Records from Bitrix core classes remain view-only.

The section is assembled visually using the mouse.

The Admin Section Builder allows configuring entities, fields, form tabs, list columns, filter fields, menu items, and their placement via the administrative interface. Fifteen field types are available: string, multiline text, HTML with markup cleaning, integer, decimal, boolean, date, date and time, value list, file, image, user, infoblock element, link to another builder entity, and color. Lists support filtering by selected fields, sorting, pagination, and bulk deletion. Forms include tabs, required fields, default values, and input validation.

Access rights are managed down to the individual field level. Access to a catalog is defined by user groups, with separate read and write permissions set for each field. A field closed for reading does not appear in the list, form, filter, export, change log, card header, or related links. For example, a manager may see a supplier catalog but cannot see the purchase price column. A link to a record in a closed catalog displays only the ID without a label. A tab for a related catalog is visible only to users with access to it. User names are displayed only to those permitted to view users, and infoblock elements are shown only from authorized sources.

Access to the information block specified in the field settings is granted with consideration for user permissions. Permission checks are performed before executing an action, not merely during page rendering.

CHANGE LOG

For each record, the system displays who made changes, when they occurred, and what was modified, showing the difference between the previous and current state for every field. The log is enabled separately for each catalog. The retention period is configured in the module settings, and an agent removes old records automatically.

EXPORT BY CURRENT FILTER

The Export button generates an XLS (SpreadsheetML) or CSV file based on the active filter, including data from all list pages up to the export_limit defined in the module settings. Rows are sorted by the primary key in ascending order, regardless of the current screen sorting. Only fields included in the list and readable by the user are exported.

SCHEMA TRANSFER BETWEEN PROJECTS

Directory descriptions are exported to a JSON file and imported to another site. Only metadata is transferred: entities, fields, settings, and access rights by group codes. Actual data remains in the original database. During import, you can choose to skip existing directories or update them. The interface does not support creating copies with new codes. If an import would require data deletion, it is not applied: the directory remains unchanged, and the list of operations is displayed for confirmation in the constructor.

DEVELOPER EXTENSION POINTS

The module provides six events with the entity code in parameters: OnAdminkitBeforeSave (returning an error cancels the save), OnAdminkitAfterSave, OnAdminkitBeforeDelete, OnAdminkitAfterDelete, OnAdminkitBuildListQuery (adjusting the list query), and OnAdminkitRenderField (custom cell rendering). Event handlers are written in the project in the standard way; editing the solution files is not required.

WHAT THE MODULE DOES NOT DO

The module does not generate PHP files in the project: the administrative section is fully managed by two pages of the solution itself. This ensures that module updates do not conflict with user modifications on the site. The system does not modify the core and does not replace standard administration pages. It does not contact external services, does not require license keys or subscriptions, and does not load third-party scripts. Execution of queries assembled from entered text is prevented: table and column names are validated against a whitelist, and data is read and written exclusively through the core ORM. Fields of type 'File' and 'Image' do not accept SVG, HTML, or other browser-executable files regardless of field settings. When deleting a solution, tables of created reference data are preserved by default; they can be removed only via a separate flag after viewing the list of tables and the number of rows in each.

The Admin Section Builder does not use information blocks as a data source due to their proprietary system of properties, permissions, and editors. The interface is built on standard administrative lists and forms of Bitrix; the ui.grid component is not used. This version lacks data import from CSV and XLS files, as well as exporting directories via REST API. Only one-to-many relationships are supported: reference fields and tabs for related records. The solution has no public part and is designed exclusively for the administrative section.

REQUIREMENTS

— 1C-Bitrix: Site Management, main module version 20.0.0 and higher;

— Highload Blocks module — optional, required only for the 'highload block' source;

— Information Blocks module — optional, required only for the 'information block element' field;

— PHP 8.2 and newer; the installer checks the PHP and main module versions;

— MySQL or PostgreSQL database. Acceptance testing was performed on MySQL 8 and PHP 8.2; verification of directory structure changes was conducted on MySQL 8 and PostgreSQL 16.

For the “Admin Section Builder” module, General iT can perform installation, configuration and a functional check in your project.