# Управление типами полей

← [К разделу «Поля документов»](README.md)

## Установлен, включён и используется — разные состояния

| Состояние | Что означает |
| --- | --- |
| Установлен | Класс присутствует в `FieldRegistry`, существующие данные можно читать. |
| Доступен для создания | Тип включён в настройке `rubrics.enabled_field_types`. |
| Используется | В `rubric_fields` есть хотя бы одно поле с этим кодом. |

Отключение в панели управления меняет только второе состояние. Это безопасный способ
сократить список для контент-менеджеров без поломки существующего сайта.

## Удаление модульного типа

Деинсталляция модуля блокируется, если хотя бы одна рубрика использует его тип.
Правильный порядок:

1. Найти поля типа в **Рубрики и поля → Типы полей**.
2. Решить судьбу каждого поля: оставить модуль, удалить поле вместе с данными
   или выполнить отдельную миграцию в другой совместимый тип.
3. Проверить публичные шаблоны и API-потребителей.
4. Только после нулевого использования деинсталлировать модуль.
5. Физически удалять пакет можно лишь после деинсталляции и только при
   `package.removable = true`.

Простая смена `rubric_field_type` в БД не является миграцией: формат значения,
настройки, числовой индекс и шаблоны могут отличаться.

## Обновление типа

Обратимо изменять можно:

- подписи и hints;
- визуальное форматирование;
- новые настройки с безопасным default;
- поддержку нового входного формата при сохранении старого чтения.

Требуют миграции:

- переименование `code()`;
- scalar ↔ JSON;
- смена ключей JSON;
- изменение единиц хранения;
- изменение смысла числового индекса;
- удаление ранее поддерживаемого значения списка.

После обновления типа пересохранение всех документов не должно быть обязательным
для обычного чтения. Если оно необходимо, модуль должен предоставить управляемую
web-операцию с пакетной обработкой и прогрессом; production не должен зависеть
от CLI.