Перенос конфигурации между площадками¶
Утилита переноса конфигурации позволяет администратору перенести настройки с одной площадки 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 сохраняются настройки «Параметры в гриде» | Они восстанавливаются вместе с ДП при импорте. Это настройка колонок табличного представления выбранных задач внутри параметра; настройки табличного представления самого источника данных — отдельная сущность (правило 33) |
| 9 | Для сквозных ДП проверяют наличие целевого ДП и категории | В целевом приложении должны быть и ДП, на который ссылается сквозной параметр, и соответствующая категория |
| 10 | ID групп в автоматизациях меняют вручную | Если группы используются в параметрах смарт-действий или в смарт-выражениях, после переноса их идентификаторы правят вручную |
| 11 | Общие смарт-выражения (SMART) выбирают вручную | В дереве экспорта — в ветке «Смарт-выражения» |
| 12 | Почтовые ящики в автоматизациях меняют вручную | После переноса указывают почтовые ящики целевой площадки |
| 13 | Настройки мобильного приложения переносят вручную | Шаблоны задач, источники данных, контейнеры, шаблоны. Привязка шаблонов к категории переносится автоматически |
| 14 | Порталы корректно переносятся только с сохранением ID | Перенос порталов работает только при импорте с сохранением идентификаторов. В архив входят блоки корневой раскладки, адаптивных раскладок (размеры экрана xs…xl) и секций Board: блок, размещённый только в секции или только на одном размере экрана, сохраняется при выгрузке и загрузке, а раскладка приёмника при домерже не затирается. Вместе с порталами переносятся JS/CSS и смарты блоков; кастомные объекты БД блоков настраивают вручную |
| 15 | Публикации переносятся со связанными объектами | Вместе с публикацией переносятся связанные объекты доступа, смарт-пакеты и представления |
| 16 | Локализованные объекты переносятся с локализациями | При конфликте идентификатора локализации утилита генерирует новые ID. Язык локализованного значения сопоставляется не по номеру, а по коду языка LangAlias (запасной путь — по культуре): справочник языков источника экспортируется в _meta/languages.json. Языка нет на приёмнике или его код неоднозначен — локализованное значение не импортируется и уходит в отчёт переноса, чужой язык не подставляется. Архив без файла языков разбирается по номеру, как раньше, с предупреждением в лог. Механизм — в режимах импорта, раздел про заглушки для ненайденных ссылок |
| 17 | Смарт-выражения и LUA-скрипты переносятся со всеми версиями | |
| 18 | Смарт-выражение при переносе на боевую площадку автоматически повышает версию | Если версии выражения на площадках различаются |
| 19 | Отдельные типы объектов можно исключить из экспорта | Настройка приложения MigrationExportSettings позволяет не выгружать выбранные типы объектов (например, права доступа групп к категории) |
| 20 | Смарт-доступ по ДП переносится вместе с параметром; при конфликте ID генерируются новые | Правило смарт-доступа тянет связанный дополнительный параметр в пакет экспорта как зависимость, поэтому на приёмнике привязка правила к параметру приезжает рабочей. Если на приёмнике уже есть запись прав с тем же ID, но другим GUID, утилита создаёт новые уникальные идентификаторы |
| 21 | Настройки сквозного ДП обновляются под приёмник | При расхождении между площадками утилита заменяет пути в настройках сквозного параметра |
| 22 | Гибкие права на задачи переносятся вместе с ДП категории | |
| 23 | Системный журнал категорий переносится по умолчанию | |
| 24 | Раздел «Статусы» можно экспортировать отдельно | Статусы экспортируются независимо от категории. Это удобно при конфликтах маршрутов (дублирующиеся идентификаторы маршрутов) |
| 25 | Права групп на категорию синхронизируются при импорте категории целиком | Права групп в целевой категории приводятся в точное соответствие с пакетом: отсутствующие в экспорте — удаляются, присутствующие — добавляются или обновляются. Работает и на MS SQL, и на PostgreSQL |
| 26 | Admin-настройки табличного представления категории и блоков «Используется» (БИ) переносятся вместе с категорией | Переносятся обе разновидности админской настройки табличного вида — и для табличного представления категории, и для каждого блока «Используется»; владелец настройки сопоставляется с объектом на приёмнике по GUID, поэтому состав и порядок колонок, ширины и фильтры совпадают с источником, даже если идентификаторы на площадках разные. Переносятся только записи без привязки к пользователю; пользовательские настройки колонок и фильтров не переносятся и пересоздаются автоматически на приёмнике |
| 27 | Параметры фильтра отчёта переносятся с сохранением ID | В стандартном режиме идентификаторы параметров фильтра сохраняются так же, как у отчёта и самого фильтра. Вместе с параметрами в архив попадают связи между зависимыми параметрами, поэтому настроенные зависимости работают на приёмнике без ручной правки |
| 28 | Валидаторы ДП переносятся вместе с категорией | Валидатор уезжает в архив следом за своими привязками — к шагу маршрута и к кнопке карточки задачи, — поэтому на приёмнике проверки значений ДП работают без ручной донастройки |
| 29 | Настройки произвольных источников данных и общие выборки переносятся с категорией | В пакет попадают настройки источника и сохранённые выборки, помеченные как общие; личные выборки и личные настройки конкретных пользователей не экспортируются. При импорте номера задач внутри сохранённых выборок пакета заменяются на номера задач приёмника — и в списке задач фильтра, и в поле отдельной задачи, и в фильтрах сохранённого вида выборки: в фильтре «Выбор значений», в мультилукап-фильтре по задачам и в конструкторе поиска (модель продвинутого фильтра); границы страницы выборки не меняются. Если личная выборка всё же оказалась в пакете, номера задач в ней заменяются так же, как в общей |
| 30 | Опрос переносится вместе со своей задачей-опросом | Если задача-опрос попадает в пакет, вместе с ней переносятся конфигурация опроса и его вопросы. Задачи попадают в пакет как записи справочника — при включённом переносе значений справочника (см. «Перенос справочников 2.0»). Назначения опросов задачам и результаты прохождения не переносятся. При импорте утилита перепривязывает ссылки на задачи и файлы внутри конфигурации опроса во всех режимах, включая стандартный, а задачу вне пакета ищет на приёмнике по GUID. Ссылка, которую не удалось сопоставить (задачи нет ни в пакете, ни на приёмнике или файла нет в пакете), остаётся прежней, а в лог переноса пишется предупреждение |
| 31 | Теги категории переносятся вместе с ней | Вместе с категорией переезжают типы тегов и маппинги тегов. При повторном переносе на приёмник, где такие теги уже есть, совпавшие записи не дублируются: утилита сопоставляет их по паре «тип тега и имя» или «тип тега, алиас параметра и внешний параметр» и переводит запись в обновление. Если маппинг источника совпал с разными записями приёмника или две записи источника ведут на одну запись приёмника, импорт прерывается с перечислением конфликтующих записей. Подробнее — в режимах импорта |
| 32 | Запись с несопоставленной обязательной ссылкой не переносится | Если обязательная ссылка — часть составного ключа или обычная обязательная ссылка — не нашлась на приёмнике ни по идентификатору, ни по GUID, утилита не подставляет вместо неё произвольную запись справочника: запись отбрасывается, а в лог переноса идёт предупреждение с типом сущности и значением ссылки. Исключение — ссылка на пользователя: вместо ненайденного подставляется системный робот. Если записей не хватает после импорта, ищите эти предупреждения в логе |
| 33 | Настройки экрана «Источник данных» лукапа и мультилукапа переносятся вместе с параметром | В пакет включаются админские настройки табличного представления источника данных: состав и порядок колонок, «Доступность», «Видимость по умолчанию», «Стиль», «Выравнивание», «Ширина», «Тип фильтра», а также общие настройки экрана — «Тип статуса», «Группировать по», «Группировать одной строкой», «Позиция закрепления». Переносятся только админские настройки; личные настройки пользователей остаются на своей площадке. Если у параметра на приёмнике уже была сохранена своя настройка источника, она заменяется настройкой площадки-источника — вторая запись не создаётся. Категорию-источник при этом по-прежнему выбирают вручную (правило 7), отдельно переносятся «Параметры в гриде» мультилукапа (правило 8) |
⚠️ Кастомных объектов БД в дереве экспорта нет. Хранимые процедуры, SQL-функции и представления (view) утилита не выгружает — отдельной ветки под них в дереве объектов нет, искать их там не нужно. Их создают на площадке-приёмнике вручную (через SSMS/psql), и только после этого настраивают зависящие от них объекты (например, SQL-представление доступа к категории).
⚠️ Повторный перенос на площадку, где настройка вида уже настроена. Админские настройки табличного вида категории и блоков «Используется» сопоставляются с приёмником по GUID: если для того же блока или категории на приёмнике уже сохранена своя настройка, перенос добавит рядом вторую запись, а не заменит существующую. Замена сохранённой настройки гарантирована только для настроек экрана «Источник данных» лукапа и мультилукапа (правило 33). Перед переносом на непустой приёмник проверьте, не настроен ли нужный блок или категория вручную.
Экспорт конфигурации¶
Администратор открывает дерево объектов, отмечает нужные элементы и выгружает их. Выгруженная конфигурация упаковывается в ZIP-архив. При импорте формат архива определяется автоматически, поэтому архивы, выгруженные разными версиями утилиты, загружаются без дополнительной подготовки.
Поиск настроек на странице экспорта¶
Чтобы не искать нужные настройки перебором в дереве объектов, над деревом есть поле поиска. Поиск, как и остальные операции переноса, доступен только администратору (God).
Поиск идёт по названию настройки (вхождение подстроки, без учёта регистра) или по точному числовому id — например, по id категории или дополнительного параметра. Запускается он, когда в поле набрано не меньше символов, чем задано настройкой приложения NumberCharactersForSearch; числовой запрос ищет с первого символа.
Поиск охватывает разделы, категории, дополнительные параметры (ДП) и ДП в составе категории. Остальные настройки, как и раньше, ищут в дереве вручную.
Найденное показывается списком, сгруппированным по типу настройки; у каждой записи видны название и её id. Записи разных типов с одинаковым числовым id показываются отдельными строками и выбираются независимо друг от друга. Найденную категорию можно раскрыть прямо из результатов и отметить в ней нужные дочерние настройки — искать её отдельно в дереве не требуется.
Отмеченные из результатов поиска настройки остаются в выборе и после очистки строки запроса. Кнопка «По умолчанию» очищает и выбор, и поиск.
Если подходящих записей больше, чем помещается в выдачу, страница об этом сообщает и предлагает уточнить запрос.
Поиск ищет только то, что есть в дереве экспорта.
Полная выгрузка¶
Кнопка «Полная выгрузка» запускает фоновую выгрузку всей конфигурации площадки. Готовый архив помещается в файловое хранилище, в папку «Файлы автоматизации / Export configurations»; доступ к нему получает группа администраторов (GodGroup). По завершении система присылает уведомление. Пока выгрузка идёт, кнопка неактивна.
Частичный экспорт и родительские разделы¶
При частичном экспорте можно выбрать отдельную категорию. Если её родительский раздел есть на источнике, но отсутствует на приёмнике, он автоматически добавляется в пакет. Если переносится весь раздел, он будет создан в целевом приложении.
Частичный экспорт выполняется сразу и ждёт ответа сервера. На больших объёмах запрос может не уложиться в отведённое время — тогда система сообщает, что выгрузить файл не удалось, и рекомендует «Полную выгрузку», которая работает в фоне.
Перенос справочников 2.0¶
Утилита переносит не только структуру категории-справочника (поля, маршруты, представления), но и сами записи справочника вместе с заполненными дополнительными параметрами. Это позволяет перенести готовый справочник целиком с одной площадки на другую. Перенос значений справочника включается отдельной опцией при экспорте.
Что попадает в пакет: - Категория справочника (название, дополнительные параметры, представления, маршруты). - Записи справочника — как задачи соответствующей категории. - Значения дополнительных параметров этих записей: lookup-связи на другие справочники, выбранные задачи и папки, табличные ДП.
Что пока не переносится: - Значения ДП типа «Выбор пользователей», «Выбор групп», «Выбор подразделений» — при экспорте по ним остаётся предупреждение в системном логе.
Ссылка на задачу вне пакета переноса. Если запись справочника через lookup ссылается на задачу, которая не вошла в пакет, утилита запоминает её GUID. При импорте она ищет задачу с этим GUID на площадке-приёмнике: если такая задача есть, ссылка автоматически привязывается к ней. Если задачи с этим GUID нет ни в пакете, ни на приёмнике, ссылка пропускается без ошибки — остальные записи импортируются штатно, а о пропущенных значениях остаётся запись в системном логе.
Ссылка на запись справочника в смарт-выражениях и скриптах. При переносе номер записи справочника подставляется автоматически, если запись перенесена в том же пакете и её номер стоит в SQL-сравнении с taskid, SelectedTaskId, NaturalValue или с колонкой ExtParam{N}NativeValue лукап-ДП - в смарт-выражениях, в SQL отчётов и в строковых литералах смарт-скриптов, которые распознаны как SQL. Номер, собранный конкатенацией, вычисленный или записанный вне такого сравнения, утилита не узнаёт и не меняет - там на запись справочника ссылаются по GUID.
Ссылки на задачи и параметры в настройках смарт-действий. Фиксированные значения параметров действий в пакетах тоже приводятся к приёмнику: номер задачи в параметрах действий «Отправить сообщение пользователю» (вставка текста и открытие задачи) и «Сгенерировать по шаблону», значение лукап-параметра и номер дополнительного параметра в действиях «Изменить значение ДП» и «Массово изменить значение ДП», а также SQL в действиях «Выполнить SQL» и «Создать или обновить смарт-фильтр» — он разбирается так же, как SQL смарт-выражений. Пользовательские действия и действия, неизвестные этой версии, пропускаются без изменений и не прерывают импорт; значение, которое не удалось разобрать или сопоставить, остаётся прежним, а в лог переноса пишется предупреждение.
Денормализация значений. После импорта утилита сама обновляет денормализованное представление справочника и пересоздаёт денорм-представления табличных ДП, чтобы значения сразу были видны в табличных представлениях, фильтрах и связанных задачах — без перезагрузки пула приложения.
Паритет PostgreSQL. На PostgreSQL поведение одиночных lookup-связей приведено к поведению MS SQL Server, поэтому импорт справочников 2.0 даёт одинаковый результат на обеих СУБД.
Несопоставленные ссылки: сводка в конце переноса. Замена идентификаторов — не блокирующая проверка: если ссылку сопоставить не удалось, импорт не прерывается, а в конце переноса утилита печатает одну сводку уровня Warn — по каждому объекту его вид, название, GUID и несопоставленные номера. Сводка идёт в системный лог приёмника и параллельно транслируется в открытое окно переноса (SignalR-хаб MigrationUtilityHub, событие notify). После переноса сводку стоит просмотреть: до первого срабатывания настройки несопоставленная ссылка внешне себя не проявляет. Иначе ведут себя обязательные ссылки в записях справочника — такая запись не переносится вовсе (см. правило 32).
Опции импорта¶
По умолчанию утилита переносит объекты с сохранением их идентификаторов: объекты сопоставляются по 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).
Конфликт по дополнительному уникальному ключу (не первичному) утилита разбирает до начала импорта: уникальный составной индекс задаёт слот записи, и по каждому такому индексу переносимых типов она проверяет, нужен ли слот пакету и освободится ли он к концу импорта. Если слот освобождает удаляемая или сдвигаемая запись, запись пакета выполняется во второй фазе, и импорт проходит штатно; если слот занят записью приёмника, которую импорт не удаляет и не сдвигает, импорт останавливается до первой записи в базу и выводит перечень конфликтов — тип записи, имя уникального индекса, значение слота и GUID конфликтующих записей, — а данные приёмника остаются неизменными. Обмен слотами между двумя переносимыми записями утилита проводит через временное значение. Если нарушение уникальности всё же происходит внутри импорта, поведение прежнее: утилита пытается обновить запись по составному первичному ключу; если записи с таким первичным ключом нет — значит, конфликт пришёлся на другой уникальный ключ, — ошибка фиксируется в журнале с указанием ключа и импорт прерывается. Дубликат по самому составному первичному ключу приводит к обновлению существующей записи.
Что делать: для конфигураций, которые загружаются на чистый стенд, перед импортом проверьте наличие seed-сущностей и при необходимости очистите базу от предзаполненных категорий, дополнительных параметров, статусов и связанных системных сущностей, оставив только минимальный технический скелет площадки.
Если содержимое приёмной базы нужно сохранить, вместо стандартного сценария выберите режим импорта с переназначением идентификаторов — «Импортировать как новые сущности» или «Импортировать без сохранения идентификаторов».
Как утилита при загрузке находит уже существующие записи приёмника (по Guid и по смысловому ключу), какие проходы трогают ссылки и что проверить, добавляя в перенос новую сущность или связь, — в руководстве разработчика.
Модули и версионирование¶
Модуль — это логическое объединение сущностей конфигурации для переноса и версионирования. В модуль обычно входят разделы, категории, ДП, статусы, подписи, отчёты, порталы, виджеты и автоматизации (смарт-пакеты, смарт-выражения, смарт-расписания).
Базовые операции с модулями:
- Создание — указать название и сохранить.
- Редактирование — изменить данные модуля в списке.
- Удаление — возможно только если в модуле нет связанных сущностей.
- Назначение — в формах администрирования у объекта есть поле «Модуль». Если модуль не выбран, объект относится к общему (глобальному) модулю.
Наследование. При создании ДП и смартов внутри категории обычно наследуется модуль этой категории. Система ограничивает смешивание сущностей разных модулей в ряде сценариев настройки.
Версионирование модулей¶
Конфигурацию модуля можно сохранять версиями в репозитории и переключаться между ними. Поддерживаются два типа репозитория: файловая система (FileSystem) и Git. Прежде чем создавать или переключать версии, нужно настроить активный репозиторий. Доступные операции — создать версию, переключить версию, удалить версию. Отдельного мастера в интерфейсе для версионирования нет: оно выполняется через программный интерфейс (API), поэтому обычно применяется в связке с интеграциями и скриптами настройки.