Закрытие записи

В Ordinis нет «удалить» в привычном смысле — данные не пропадают. Вместо этого запись закрывается: ей выставляется valid_to = текущий момент, после чего она перестаёт считаться актуальной, но история остаётся.

Зачем так

Bitemporal модель — два временных измерения:

valid_from / valid_to — когда запись актуальна в реальном мире
created_at / updated_at — когда запись была введена в систему

Это позволяет:

Восстанавливать что было «на дату» (например, состав группировки спутников на 2024-12-31)
Видеть, кто и когда вносил изменения
Не ломать downstream-системы, которые могут читать архивные данные

Когда закрывать запись

Спутник выведен из эксплуатации
Наземная станция демонтирована
Контракт истёк
Тип записи переименован (закрыть старую, открыть новую с новым кодом)
Дубликат обнаружен (оставить одну, закрыть остальные)

Как закрыть

Открой запись в drawer'е
Кнопка «Удалить» в footer'е (она же — «закрыть»)
Опционально укажи valid_to — момент закрытия. По умолчанию: сейчас.
Подтверди

После этого:

В UI запись по умолчанию не отображается (фильтр «только активные»)
В API при GET /records?at=YYYY-MM-DD — отображается только если на эту дату была активна
История доступна через GET /records/{id}/history

Как восстановить

Если запись закрыта ошибочно — открой панель «История версий» в drawer'е, найди последнюю активную версию до закрытия, нажми «Восстановить как новую запись». Это создаст новую активную версию с тем же бизнес-ключом, что и закрытая.

Альтернатива: создать запись с тем же бизнес-ключом заново — система проверит, что нет пересекающихся периодов действия.

Bulk-закрытие при cascade

Если запись X используется в других справочниках (через x-references), система проверит ссылки:

Если есть активные записи, ссылающиеся на X — будет предупреждение
Можно: (а) сначала закрыть/обновить зависимые записи, (б) принять риск orphan'ов (downstream consumers получат FK-misses)

См. Cross-references (FK) о том, как зависимости валидируются на уровне API.

Закрытие vs полное удаление

Полное удаление записи (DELETE из БД) не поддерживается через UI и обычный API. Это намеренно — целостность истории важнее «чистоты».

Если ОЧЕНЬ нужно (например, по GDPR / по приказу) — администратор выполняет это через специальную процедуру с подтверждением. Свяжись с ответственным за систему.

Что произойдёт при закрытии

В БД у записи обновляется valid_to
В Kafka-топик публикуется событие RecordClosed с указанием valid_to и причины (если задана)
В audit log пишется операция CLOSE с привязкой к оператору
Downstream consumers (Альтум, BI) видят новую версию состояния справочника на следующем чтении (или сразу через событие)

Чек-лист перед закрытием

Я уверен, что закрываю правильную запись (бизнес-ключ совпадает)
Если у записи есть зависимости через FK — я их проверил
valid_to соответствует реальному моменту вывода из эксплуатации (не «сейчас» по умолчанию, если эксплуатация закончилась в прошлом)
Я понимаю: история останется, downstream-консьюмеры узнают

5.2 KiB Raw Blame History Unescape Escape