Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
В трёх подразделениях заведены поля «Поставщик», «Вендор» и «Контрагент». Они означают одно и то же, но содержат разные справочники. Общий отчёт считает только часть закупок, а интеграция вынуждена знать три идентификатора пользовательских полей.
Сначала выберите один отчёт, который сейчас собирается неправильно, и сделайте его критерием успеха. Тогда объединение полей останется решением конкретной проблемы данных. Избегайте миграции только ради административной аккуратности, если разные подразделения вкладывают в похожие названия существенно разный бизнес-смысл.
Модель и договорённости
Сначала определите бизнес-понятие: юридическое лицо, торговая марка и сервисная команда не всегда являются одним поставщиком. Для совпадающих понятий выберите одно целевое поле и отдельные контексты там, где нужен разный набор вариантов. Сохраните таблицу соответствия старых идентификаторов и значений новым.
Сопоставление значений оформите как явную таблицу с колонками источник, старое значение, целевое значение и решение владельца. Пустота, неизвестное значение и отсутствие применимости должны различаться. При слиянии справочников важно сохранить это различие, иначе отчёт покажет красивые, но недостоверные категории.
Порядок внедрения
Снимите выборку заполненных значений и найдите использование полей в экранах, автоматизациях, фильтрах и внешних выгрузках. Подготовьте целевые контексты на ограниченном наборе проектов. Переносите данные небольшими партиями с отдельным маркером миграции. Старые поля сначала уберите из ввода, сохранив возможность сравнить историю и исправить сопоставление.
Миграцию полезно вести по одному подразделению, сохраняя карту зависимости каждого поля. В первой партии включите актуальные и исторические задачи, а также исключительные значения справочника. После сверки данных обновляйте потребителей целевого поля по одному: форму создания, автоматизацию, отчёт и интеграционный запрос. Это позволяет локализовать отказ конкретного потребителя.
Проверки на реальных сценариях
Проверьте создание и редактирование задачи каждого типа, обязательность значения и доступные варианты в разных проектах. Сравните количество заполненных задач до и после миграции, включая архивные периоды. Прогоните отчёт и одну реальную интеграционную операцию: одинаковое отображаемое имя не означает одинаковый идентификатор API.
Добавьте задачу с историческим значением, которого больше нет среди актуальных вариантов, и задачу из другого проекта. Проверьте не только редактирование, но и сохранение без изменения поля. Неожиданная обязательность может заблокировать обычную работу на старых задачах, даже если новые создаются без проблем.
Ошибки и диагностика
Частый дефект — сопоставить два похожих названия поставщиков без проверки юридического смысла. Другой — ограничить контекст и оставить автоматизацию записывающей значение, которого в нём больше нет. Не очищайте неизвестные значения молча: складывайте их в список ручного разбора с ключом задачи и исходным содержимым.
Неизвестное значение поставщика оставляйте исключением до решения владельца данных. Автоматический выбор самого похожего названия создаёт незаметную ошибку, которая потом распространяется в финансовые и операционные отчёты.
Возврат и восстановление
Сохраните выгрузку ключей задач и обоих значений перед каждой партией. При проблеме остановите новые записи в целевое поле, восстановите старые экраны и обратите только документированную партию. Не удаляйте старые поля до завершения контрольного периода: удаление усложняет возвращение фильтров, данных и пользовательских привычек.
При обратном переносе сверяйте не только исходную выгрузку, но и изменения пользователей, сделанные после миграции. Новое значение поставщика нельзя бездумно заменить старым. Для каждой затронутой задачи сохраните обе версии и решение владельца справочника, а затем повторите отчёт, который был исходным критерием успешного объединения полей.
Приёмка и дальнейший контроль
Оценивайте число дублей, долю задач с неизвестным поставщиком и количество интеграционных ошибок сопоставления. Успех означает единый смысл данных и воспроизводимый отчёт, а не минимальное число полей любой ценой. Владелец справочника должен согласовывать новые варианты и периодически проверять, не появились ли новые синонимы.
Владелец поля поддерживает описание смысла, правила добавления вариантов и перечень интеграций. Это снижает вероятность, что через месяц появится новое поле с тем же назначением. Для устаревшего поля укажите срок выключения и условие удаления, связанное с проверенной миграцией потребителей и истории.
Механизм продукта и применимость
Контекст позволяет ограничить применимость поля проектами и типами задач, задать варианты и значения по умолчанию. Изменение контекста затрагивает всех его потребителей, поэтому оно требует анализа зависимостей.
Статья рассматривает административные контексты общих полей Jira Cloud. В team-managed проекте локальные поля и их настройка отличаются; сначала выясните происхождение конкретного поля. Общая рекомендация о едином бизнес-смысле применима шире, но шаги объединения и ограничения контекста выбирают по фактической конфигурации.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу