Перенос конфигурации между площадками¶
Утилита переноса конфигурации позволяет администратору перенести настройки с одной площадки 1Формы на другую. Через неё переносят категории и разделы, дополнительные параметры (ДП), статусы и маршруты, порталы, отчёты, публикации, автоматизации (смарт-пакеты, смарт-выражения, смарт-расписания) и другие элементы конфигурации. Переносятся именно настройки — рабочие данные (задачи, комментарии, пользовательские файлы) утилита не выгружает (исключение — записи справочников 2.0, см. ниже). Администратор выбирает нужные объекты в дереве, выгружает их в архив на площадке-источнике и загружает этот архив на площадке-приёмнике. Инструмент рассчитан на администратора или настройщика площадки и работает через раздел администрирования.
Кто может переносить конфигурацию¶
Перенос конфигурации между площадками — импорт и экспорт архива, предпросмотр импорта, просмотр дерева объектов, полная фоновая выгрузка — доступен только пользователям с правами администратора (God). Пользователь или сервисная учётная запись без прав администратора получает отказ в доступе. Ограничение действует одинаково и для операций в интерфейсе администрирования, и для вызовов через MCP-сервер миграции.
Практическое следствие: интеграции и автоматизации, которые обращались к переносу конфигурации под неадминистративной учётной записью, нужно перевести на учётную запись администратора.
Важные условия и ограничения¶
⚠️ Версии площадок должны совпадать. Экспорт и импорт конфигурации предназначены не для обновления платформы, а только для переноса настроек между экземплярами одной версии, поэтому версии площадки-источника и площадки-приёмника должны совпадать. Утилита поддерживает и кросс-версионный перенос: при расхождении версий она автоматически создаёт заглушки для недостающих зависимостей (категории, группы, справочники) и сопоставляет объекты по GUID. Если на приёмнике нет таблиц или колонок из более новой версии, сначала выполняют миграцию схемы базы (dbdeploy).
⚠️ Площадка-приёмник должна быть «чистой». На приёмнике не должно быть заранее созданных сущностей — кроме пользователей, оргструктуры и групп пользователей. Все настройки должны попадать в базу только через перенос. Иначе возможны конфликты идентификаторов и перезапись чужих данных.
⚠️ Для лога в реальном времени нужен доступный endpoint /migrationUtilityHub. Чтобы на странице переноса в реальном времени обновлялись лог и статусы, через reverse proxy должен быть доступен SignalR-endpoint /migrationUtilityHub. Без него экспорт всё равно выполнится (как фоновая операция), но интерфейс не будет показывать обновления статуса.
Без остановки приложения. Перенос не требует остановки приложения. Новые настройки применяются без перезагрузки пула приложения.
Что переносится, а что настраивается вручную¶
При переносе объекты сопоставляются по GUID, а не по ID — это защищает от дублирования. Ниже собраны все правила и особенности переноса: что переносится автоматически, что тянется вместе со связанными объектами, а что нужно донастроить на приёмнике вручную.
| № | Правило | Пояснение |
|---|---|---|
| 1 | Данные задач и пользовательские файлы не переносятся | Утилита выгружает только настройки и отдельные объекты (например, перечисления). Рабочие данные задач и вложения остаются на источнике |
| 2 | Кастомные объекты БД настраиваются вручную | Хранимые процедуры, SQL-функции, представления (view), настройки табличного вида, шаблоны файлов (печатные формы) утилита не переносит — их создают на приёмнике вручную (см. предупреждение ниже) |
| 3 | При переносе ДП переносятся только его настройки | Связанные категории, разделы, сводные разделы и другие ДП нужно выбирать в дереве вручную. Исключение: привязка ДП к блокам и доступ к ДП на статусах включаются автоматически |
| 4 | При переносе категории подтягиваются связанные группы | Группы с правами на категорию, ответственная группа, группа уведомления о превышении плана, группы из настроек доступа к ДП и из уведомлений |
| 5 | Состав группы (участники) не переносится | При переносе группы создаётся только сама группа с тем же ID; список её участников не передаётся |
| 6 | Объекты, удалённые на источнике, удаляются и на приёмнике | Касается ДП, подписей на переходе, JS/CSS-вставок, кнопок, произвольных событий, блоков «Используется», блоков ДП. Важно учитывать при повторном (инкрементальном) переносе |
| 7 | Для lookup/multilookup ДП категорию-источник выбирают вручную | При первом переносе такого ДП или после изменений в категории-источнике. Если ДП настроен на сводный раздел — выбирают сам раздел и входящие в него категории |
| 8 | При экспорте multilookup сохраняются настройки «Параметры в гриде» | Они восстанавливаются вместе с ДП при импорте |
| 9 | Для сквозных ДП проверяют наличие целевого ДП и категории | В целевом приложении должны быть и ДП, на который ссылается сквозной параметр, и соответствующая категория |
| 10 | ID групп в автоматизациях меняют вручную | Если группы используются в параметрах смарт-действий или в смарт-выражениях, после переноса их идентификаторы правят вручную |
| 11 | Общие смарт-выражения (SMART) выбирают вручную | В дереве экспорта — в ветке «Смарт-выражения» |
| 12 | Почтовые ящики в автоматизациях меняют вручную | После переноса указывают почтовые ящики целевой площадки |
| 13 | Настройки мобильного приложения переносят вручную | Шаблоны задач, источники данных, контейнеры, шаблоны. Привязка шаблонов к категории переносится автоматически |
| 14 | Порталы корректно переносятся только с сохранением ID | Перенос порталов работает только при импорте с сохранением идентификаторов. Вместе с порталами переносятся JS/CSS и смарты блоков; кастомные объекты БД блоков настраивают вручную |
| 15 | Публикации переносятся со связанными объектами | Вместе с публикацией переносятся связанные объекты доступа, смарт-пакеты и представления |
| 16 | Локализованные объекты переносятся с локализациями | При конфликте идентификатора локализации утилита генерирует новые ID |
| 17 | Смарт-выражения и LUA-скрипты переносятся со всеми версиями | |
| 18 | Смарт-выражение при переносе на боевую площадку автоматически повышает версию | Если версии выражения на площадках различаются |
| 19 | Отдельные типы объектов можно исключить из экспорта | Настройка приложения MigrationExportSettings позволяет не выгружать выбранные типы объектов (например, права доступа групп к категории) |
| 20 | Смарт-доступ по ДП: при конфликте ID генерируются новые | Если на приёмнике уже есть запись прав с тем же ID, но другим GUID, утилита создаёт новые уникальные идентификаторы |
| 21 | Настройки сквозного ДП обновляются под приёмник | При расхождении между площадками утилита заменяет пути в настройках сквозного параметра |
| 22 | Гибкие права на задачи переносятся вместе с ДП категории | |
| 23 | Системный журнал категорий переносится по умолчанию | |
| 24 | Раздел «Статусы» можно экспортировать отдельно | Статусы экспортируются независимо от категории. Это удобно при конфликтах маршрутов (дублирующиеся идентификаторы маршрутов) |
| 25 | Права групп на категорию синхронизируются при импорте категории целиком | Права групп в целевой категории приводятся в точное соответствие с пакетом: отсутствующие в экспорте — удаляются, присутствующие — добавляются или обновляются. Работает и на MS SQL, и на PostgreSQL |
⚠️ Кастомных объектов БД в дереве экспорта нет. Хранимые процедуры, SQL-функции и представления (view) утилита не выгружает — отдельной ветки под них в дереве объектов нет, искать их там не нужно. Их создают на площадке-приёмнике вручную (через SSMS/psql), и только после этого настраивают зависящие от них объекты (например, SQL-представление доступа к категории).
Экспорт конфигурации¶
Администратор открывает дерево объектов, отмечает нужные элементы и выгружает их. Выгруженная конфигурация упаковывается в ZIP-архив. При импорте формат архива определяется автоматически, поэтому архивы, выгруженные разными версиями утилиты, загружаются без дополнительной подготовки.
Полная выгрузка¶
Кнопка «Полная выгрузка» запускает фоновую выгрузку всей конфигурации площадки. Готовый архив помещается в файловое хранилище, в папку «Файлы автоматизации / Export configurations»; доступ к нему получает группа администраторов (GodGroup). По завершении система присылает уведомление. Пока выгрузка идёт, кнопка неактивна.
Частичный экспорт и родительские разделы¶
При частичном экспорте можно выбрать отдельную категорию. Если её родительский раздел есть на источнике, но отсутствует на приёмнике, он автоматически добавляется в пакет. Если переносится весь раздел, он будет создан в целевом приложении.
Перенос справочников 2.0¶
Утилита переносит не только структуру категории-справочника (поля, маршруты, представления), но и сами записи справочника вместе с заполненными дополнительными параметрами. Это позволяет перенести готовый справочник целиком с одной площадки на другую. Перенос значений справочника включается отдельной опцией при экспорте.
Что попадает в пакет: - Категория справочника (название, дополнительные параметры, представления, маршруты). - Записи справочника — как задачи соответствующей категории. - Значения дополнительных параметров этих записей: lookup-связи на другие справочники, выбранные задачи и папки, табличные ДП.
Что пока не переносится: - Значения ДП типа «Выбор пользователей», «Выбор групп», «Выбор подразделений» — при экспорте по ним остаётся предупреждение в системном логе.
Ссылка на задачу вне пакета переноса. Если запись справочника через lookup ссылается на задачу, которая не вошла в пакет, утилита запоминает её GUID. При импорте она ищет задачу с этим GUID на площадке-приёмнике: если такая задача есть, ссылка автоматически привязывается к ней. Если задачи с этим GUID нет ни в пакете, ни на приёмнике, ссылка пропускается без ошибки — остальные записи импортируются штатно, а о пропущенных значениях остаётся запись в системном логе.
Денормализация значений. После импорта утилита сама обновляет денормализованное представление справочника и пересоздаёт денорм-представления табличных ДП, чтобы значения сразу были видны в табличных представлениях, фильтрах и связанных задачах — без перезагрузки пула приложения.
Паритет PostgreSQL. На PostgreSQL поведение одиночных lookup-связей приведено к поведению MS SQL Server, поэтому импорт справочников 2.0 даёт одинаковый результат на обеих СУБД.
Опции импорта¶
По умолчанию утилита переносит объекты с сохранением их идентификаторов: объекты сопоставляются по GUID, уже существующие на приёмнике обновляются, а новые добавляются с тем же ID, что и на источнике. Это стандартный сценарий переноса настроек между площадками одной версии.
После выбора файла миграции становятся доступны дополнительные опции:
| Опция | Что делает |
|---|---|
| Нужна денормализация | Запускает денормализацию переносимых категорий. Гарантированно применяется при полном переносе категории. При частичном импорте (только новые ДП или блоки) автоматическая денормализация может не обновить структуру денорм-таблицы — тогда денормализацию выполняют вручную после импорта. Для сводного раздела опция обязательна |
| Загружать все резолюции | По умолчанию резолюции из статических подписей не импортируются вместе с категорией; опция включает их перенос |
| Импортировать как новые сущности | Все объекты создаются заново — с новыми GUID и идентификаторами, которые выдаёт площадка-приёмник. Получается независимая копия конфигурации, не связанная с источником по ID. Автором версий указывается служебная учётная запись «Робот 1Ф». Исключения: системные статусы «Новая», «Выполняется», «Завершена», «Отклонена» не дублируются; служебные группы Administrators, «Исключить из чатов», «Включить в чаты» проверяются по общим настройкам приложения |
| Импортировать без сохранения идентификаторов | Объекты сопоставляются по GUID: уже существующие обновляются с сохранением своих прежних ID, новые добавляются с идентификаторами приёмника. После импорта утилита сама заменяет ID в смарт-выражениях, ссылки в JSON-настройках порталов и параметры смарт-правил. Предназначен для обновления боевой площадки конфигурацией со стенда разработки, когда идентификаторы объектов разошлись |
Какой режим переноса выбрать:
- Стандартный перенос (с сохранением ID) — обычный перенос настроек между площадками одной версии. Никаких дополнительных опций включать не нужно: объекты сопоставляются по GUID, существующие обновляются, новые добавляются с прежними идентификаторами.
- Импортировать как новые сущности — когда нужна независимая копия конфигурации с новыми идентификаторами (например, размножить готовую настройку на новом стенде).
- Импортировать без сохранения идентификаторов — когда обновляют боевую площадку конфигурацией со стенда разработки, а ID объектов на площадках уже разошлись.
⚠️ Режим «Импортировать без сохранения идентификаторов» доступен только в утилите командной строки и в WinForms-версии. В веб-интерфейсе (раздел администрирования) этой опции нет.
Предпросмотр (Preview)¶
Кнопка «Проверить» запускает анализ переносимых объектов. В таблице предпросмотра показываются:
| Колонка | Что показывает |
|---|---|
| Название | Название переносимого объекта |
| Таблица | Таблица базы данных приёмника |
| GUID | GUID переносимого объекта |
| Статус | Один из четырёх статусов (см. ниже) |
| Изменённые поля | Только для статуса «Обновить» — список отличающихся полей до запуска импорта |
Статусы предпросмотра:
| Статус | Значение |
|---|---|
| Добавить | Объект отсутствует на приёмнике и будет добавлен |
| Обновить | Объект есть на приёмнике, но будет обновлён; доступен список изменённых полей |
| Конфликт | Объект с таким идентификатором уже есть, загрузка невозможна |
| Без изменений | Объект одинаков на источнике и приёмнике |
Опция «Показать только изменяемые» скрывает записи со статусом «Без изменений».
После импорта¶
После завершения импорта рекомендуется:
- Вручную проверить корректность перенесённых настроек.
- Очистить кеш.
- Выполнить денормализацию категорий, для которых переносились настройки.
- Перезапустить пул приложения.
Импорт на непустую базу¶
При стандартном импорте (с сохранением идентификаторов) утилита добавляет объекты с теми же ID, что и на источнике. Из-за этого даже на, казалось бы, пустой базе возможны конфликты первичных ключей, если в ней уже есть предзаполненные (seed) данные платформы.
Типовой пример — конфликт по дополнительным параметрам: один и тот же внутренний идентификатор может быть занят разными ДП в импортируемом пакете и в seed-данных базы. В этом случае импорт прерывается ошибкой нарушения первичного ключа (Violation of PRIMARY KEY constraint).
Что делать: для конфигураций, которые загружаются на чистый стенд, перед импортом проверьте наличие seed-сущностей и при необходимости очистите базу от предзаполненных категорий, дополнительных параметров, статусов и связанных системных сущностей, оставив только минимальный технический скелет площадки.
Если содержимое приёмной базы нужно сохранить, вместо стандартного сценария выберите режим импорта с переназначением идентификаторов — «Импортировать как новые сущности» или «Импортировать без сохранения идентификаторов».
Модули и версионирование¶
Модуль — это логическое объединение сущностей конфигурации для переноса и версионирования. В модуль обычно входят разделы, категории, ДП, статусы, подписи, отчёты, порталы, виджеты и автоматизации (смарт-пакеты, смарт-выражения, смарт-расписания).
Базовые операции с модулями:
- Создание — указать название и сохранить.
- Редактирование — изменить данные модуля в списке.
- Удаление — возможно только если в модуле нет связанных сущностей.
- Назначение — в формах администрирования у объекта есть поле «Модуль». Если модуль не выбран, объект относится к общему (глобальному) модулю.
Наследование. При создании ДП и смартов внутри категории обычно наследуется модуль этой категории. Система ограничивает смешивание сущностей разных модулей в ряде сценариев настройки.
Версионирование модулей¶
Конфигурацию модуля можно сохранять версиями в репозитории и переключаться между ними. Поддерживаются два типа репозитория: файловая система (FileSystem) и Git. Прежде чем создавать или переключать версии, нужно настроить активный репозиторий. Доступные операции — создать версию, переключить версию, удалить версию. Отдельного мастера в интерфейсе для версионирования нет: оно выполняется через программный интерфейс (API), поэтому обычно применяется в связке с интеграциями и скриптами настройки.