demo, iblock формы), расположение и права доступа для работы с конфигами и мастеромlink

В SF4 админ-инструменты обычно группируются вокруг двух задач:

Настройки уровней (site/section/page) — это страницы/формы, которые позволяют менять значения свойств для конкретного уровня и сохранять их в слой данных сайта. В вашем проекте видно, что для уровней предусмотрены отдельные админ-страницы:

/bitrix/admin/simai/site_property.php
/bitrix/admin/simai/section_property.php
/bitrix/admin/simai/page_property.php

А в шаблоне проекта предусмотрена механика открытия этих страниц в диалоговом окне (BX.CDialog). В текущем panel.php кнопка диалогов свойств закомментирована, но сама инфраструктура (параметры диалога и URL) уже подготовлена.

Редактор данных инфоблоков (элементы/разделы) — это отдельная линия: она про редактирование контента, а не про “конфигурацию инфоблока”. Вы отдельно подтвердили: публичного конфигуратора инфоблоков у вас нет, но редактор данных элементов/разделов и конфиги форм — есть.

По мастеру (wizard): он технически вызывается компонентом на любой странице (чаще — отдельной служебной странице/разделе), и опирается на WIZARD_DIR + .wizard.config.php.

Права: какие роли/группы должны иметь доступ к админ-разделу SF4 и к записям в `{site_dir}/simai.data`link

Здесь всегда два независимых слоя прав:

Права Bitrix (кто может открыть инструмент)

Для панелей/кнопок в вашем проекте явно используется условие “только администратор”: панельные кнопки добавляются в panel.php только при $USER->IsAdmin().
Для редактирования данных инфоблока (элементы/разделы) обычно дополнительно важны права на сам инфоблок (право записи), иначе редактирование должно быть заблокировано или ограничено.

Права файловой системы (куда можно сохранить результат)

Любые операции, которые сохраняют конфиги/шаблоны/данные в {site_dir}/simai.data, требуют прав записи веб-сервера в соответствующие каталоги (как минимум simai.data/config, simai.data/template, simai.data/grid, если вы туда пишете).

Типовой практический ориентир для документации: если инструмент “открывается, но не сохраняет”, сначала проверяются права на запись в simai.data, а уже затем — логика формы/валидация.

Файловый менеджер: использование админ-страниц для создания шаблонов grid/block/view внутри `simai.data`link

Этот пункт зависит от того, включён ли у вас в проекте именно “инструмент создания файлов из админки”.

Что можно описать как устойчивый принцип SF4 (и как правильную практику даже без спец-интерфейса):

любые новые шаблоны view/block должны появляться в {site_dir}/simai.data/grid/...,
любая новая область шаблона должна появляться в {site_dir}/simai.data/template/area/.../template.php,
любые правки CSS/JS/meta/panel/property должны оставаться в {site_dir}/simai.data/template/....

Если у вас действительно есть админ-страницы, которые создают папки/файлы в simai.data (по типу “создать новый block/view”), то документацию лучше строить вокруг “что создаётся” и “куда сохраняется”, потому что это самое критичное для сопровождения. Если такого интерфейса нет — процесс остаётся ручным (копирование шаблонов и правка файлов), и это тоже нормально.

Публичный редактор инфоблоков: что редактирует (данные элементов/разделов), какие уровни настроек учитывает (user/page/section/site), как подключается и где доступны формыlink

Здесь важно разделить два понятия:

Публичный конфигуратор инфоблоков (настройка состава/типа полей инфоблока через UI) — у вас не реализован.
Редактор данных инфоблока (редактирование элементов и разделов) — у вас есть, и он опирается на конфигурации форм.

Конфигурации форм в вашем проекте представлены двумя файлами:

.iblock.config.php — схемы форм для элементов (по кодам сущностей/контента)
.iblock.section.config.php — схемы форм для разделов

Как устроена схема:

верхний уровень — “код набора” (например, doc-page, news, event и т.д. для элементов; structure, service, job и т.д. для разделов);
внутри — вкладки/секции формы (edit1, edit2, main и т.п.);
внутри секции — property, где перечислены поля.

Поля описываются минимально: name, type и иногда template. В ваших конфигах реально используются типы:

string, number, datetime, html, file, list, checkbox, а также встречаются link и map
для checkbox используется шаблон отображения sf4.switch (переключатель)

Пример (по смыслу) для элемента doc-page, вкладка edit1:

return [
    'doc-page' => [
        'edit1' => [
            'property' => [
                'ACTIVE' => ['type' => 'checkbox', 'template' => 'sf4.switch'],
                'ACTIVE_FROM' => ['type' => 'datetime'],
                'ACTIVE_TO' => ['type' => 'datetime'],
                'NAME' => ['type' => 'string'],
                'CODE' => ['type' => 'string'],
                'SORT' => ['type' => 'number'],
                'PROPERTY_FILE' => ['type' => 'file'],
                'PROPERTY_LINK' => ['type' => 'link'],
                'PROPERTY_FILES' => ['type' => 'file'],
            ],
        ],
        'edit2' => [
            'property' => [
                'IBLOCK_SECTION_ID' => ['type' => 'list'],
            ],
        ],
    ],
];

Пример для разделов (набор structure, секция main), где видно, что поддерживаются и пользовательские поля UF_*:

return [
    'structure' => [
        'main' => [
            'property' => [
                'ACTIVE' => ['type' => 'checkbox', 'template' => 'sf4.switch'],
                'NAME' => ['type' => 'string'],
                'CODE' => ['type' => 'string'],
                'UF_FIO' => ['type' => 'string'],
                'UF_ADDRESS' => ['type' => 'string'],
                'UF_SITE' => ['type' => 'string'],
                'UF_EMAIL' => ['type' => 'string'],
                'UF_POST' => ['type' => 'string'],
                'UF_DIVISION' => ['type' => 'string'],
                'UF_SECTION' => ['type' => 'string'],
            ],
        ],
    ],
];

Про “учёт уровней user/page/section/site” в редакторе данных: в текущей схеме конфигов видно, что формы описаны как набор полей и типов, но явная логика “на каком уровне что переопределяется” относится скорее к настройкам SF4 (site/section/page), чем к редактированию данных инфоблоков. Если у вас есть правило вроде “на этой странице показывать дополнительные поля” (зависит от property уровня page/user), это лучше зафиксировать отдельным пунктом — но для этого нужен 1 пример такого условия в проекте.

Отдельная процедура: создание/редактирование шаблонов грида/блоков через админкуlink

Даже если у вас есть UI-инструмент для создания файлов, безопасная процедура для SF4 обычно одинаковая:

Выбрать базовый системный шаблон (view/block), который ближе всего к нужному виду.
Скопировать его в слой данных:
- {site_dir}/simai.data/grid/view/... для view
- {site_dir}/simai.data/grid/block/... для block
Править копию, а не системный шаблон:
- template.php — разметка/логика
- при необходимости — стили/скрипты, которые подключаются проектным способом (через шаблон/ассеты проекта)
Проверить права на запись и то, что новый вариант действительно выбирается по коду/пути (а не остаётся “мертвым файлом”).
Проверить результат на странице, где этот view/block используется.

Если вы захотите добавлять “откат копирования файлов”, это как раз та точка, где придётся расширять процесс: перед file.copy складывать заменяемые файлы в backup-папку внутри пакета мастера (или рядом), чтобы был шанс вернуться назад.

Шаблон содержимого раздела: перечень страниц админки, модель прав (группы/роли), список сущностей, типовые ошибки прав/записи и способы исправленияlink

Чтобы этот раздел в документации был пригоден “как инструкция”, удобно фиксировать однотипный шаблон:

Страницы/точки входа
- Настройки уровней: site / section / page (админ-страницы SF4)
- Редактор данных инфоблоков: элементы / разделы (где именно открывается в вашем решении — отдельно зафиксировать)
- Wizard: служебная страница запуска мастера + указание WIZARD_DIR
Модель прав
- Кто видит панель/кнопки (у вас: администратор)
- Кто может редактировать инфоблоки (права на инфоблок)
- Кто может сохранять файлы в simai.data (права файловой системы)
Сущности
- Конфиги уровней: site/section/page
- Редактор данных: элементы/разделы инфоблока
- Grid/view/block (если используете)
Типовые ошибки
- “Не сохраняется” → проверить права записи в simai.data
- “Не видно кнопку/панель” → проверить роль (админ/не админ) и подключение panel.php
- “Форма не открывается/пустая” → проверить права на инфоблок + наличие схемы формы (код набора в .iblock*.config.php)
- “Шаблон view/block не применился” → проверить путь/код и что используется именно проектная копия в simai.data