feat(topbar): «Что нового» button + 2026-05-12 state.md update

2026-05-12 17:05:24 +00:00
parent 58dd871808
commit a34c6d4c82
21 changed files with 1853 additions and 8 deletions
@@ -0,0 +1,85 @@
+# Закрытие записи
+
+В Ordinis нет «удалить» в привычном смысле — данные не пропадают. Вместо
+этого запись **закрывается**: ей выставляется `valid_to = текущий момент`,
+после чего она перестаёт считаться актуальной, но история остаётся.
+
+## Зачем так
+
+Bitemporal модель — два временных измерения:
+- **valid_from / valid_to** — когда запись актуальна в реальном мире
+- **created_at / updated_at** — когда запись была введена в систему
+
+Это позволяет:
+- Восстанавливать что было «на дату» (например, состав группировки
+  спутников на 2024-12-31)
+- Видеть, кто и когда вносил изменения
+- Не ломать downstream-системы, которые могут читать архивные данные
+
+## Когда закрывать запись
+
+- Спутник **выведен из эксплуатации**
+- Наземная станция **демонтирована**
+- Контракт **истёк**
+- Тип записи **переименован** (закрыть старую, открыть новую с новым кодом)
+- Дубликат **обнаружен** (оставить одну, закрыть остальные)
+
+## Как закрыть
+
+1. Открой запись в drawer'е
+2. Кнопка **«Удалить»** в footer'е (она же — «закрыть»)
+3. Опционально укажи `valid_to` — момент закрытия. По умолчанию: сейчас.
+4. Подтверди
+
+После этого:
+- В 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)](../integration/api/x-references.md) о том,
+как зависимости валидируются на уровне API.
+
+## Закрытие vs полное удаление
+
+**Полное удаление записи (DELETE из БД) не поддерживается** через UI и
+обычный API. Это намеренно — целостность истории важнее «чистоты».
+
+Если ОЧЕНЬ нужно (например, по GDPR / по приказу) — администратор
+выполняет это через специальную процедуру с подтверждением. Свяжись с
+ответственным за систему.
+
+## Что произойдёт при закрытии
+
+- В БД у записи обновляется `valid_to`
+- В Kafka-топик публикуется событие `RecordClosed` с указанием
+  `valid_to` и причины (если задана)
+- В audit log пишется операция `CLOSE` с привязкой к оператору
+- Downstream consumers (Альтум, BI) видят новую версию состояния
+  справочника на следующем чтении (или сразу через событие)
+
+## Чек-лист перед закрытием
+
+- [ ] Я уверен, что закрываю правильную запись (бизнес-ключ совпадает)
+- [ ] Если у записи есть зависимости через FK — я их проверил
+- [ ] `valid_to` соответствует реальному моменту вывода из эксплуатации
+      (не «сейчас» по умолчанию, если эксплуатация закончилась в прошлом)
+- [ ] Я понимаю: история останется, downstream-консьюмеры узнают