006 Пользователи: API /users (CRUD, смена своего пароля), раздел UI «Пользователи»,
события журнала user.*, защита от отключения/удаления себя и последнего админа.
007 Исправление удаления организации: VRF удаляются явным DELETE до организации
(без relationship() порядок DELETE не гарантирован → ложный 409).
008 Журнал фиксирует отказы в удалении (<entity>.delete_blocked) со списком
мешающих объектов в «Данных»: организация, VRF, тип устройства, префикс, пользователь.
009 Выбор строк чекбоксами и групповые операции в UI (удаление, смена типа устройств,
статус префиксов и адресов, доступ пользователей); цикл запросов из UI, итог и список отказов.
010 Автовыделение следующего вложенного префикса: POST/GET /prefixes/{id}/subnets/next,
первый свободный выровненный блок; пункт «Добавить вложенный (авто)» в меню префикса.
Тесты: 14 (добавлены сценарии для 006, 007/008, 010); исправлена нестабильность
тестов журнала (IPv6-группы с ведущими нулями нормализуются PostgreSQL).
Документация: README.md, docs/changes/006-010 (планы и итоги).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2.2 KiB
2.2 KiB
Итог: исправление удаления организации (изменение 007)
Проблема
DELETE /api/v1/organizations/{id} возвращал 409 «Запись с такими значениями уже существует» для организаций без префиксов, устройств и операторов.
Причина
В delete_org служебные VRF и сама организация удалялись одним commit() через db.delete(). Между Vrf и Organization нет ORM-relationship(),
поэтому порядок DELETE в unit of work не гарантирован: DELETE FROM organizations выполнялся раньше DELETE FROM vrfs и нарушал FK vrfs_organization_id_fkey.
Ошибка IntegrityError в commit() превращалась в общий 409. Тесты проблему не видели: фикстура org перед удалением организации вручную удаляет её VRF.
Что сделано
app/api/v1/refs.py: VRF организации удаляются явнымdb.execute(delete(Vrf).where(...))до удаления организации.tests/test_api.py:test_delete_organization— организация с префиксом → 409 «Нельзя удалить…»; пустая организация (VRFdefaultудаляется вместе с ней) → 204, затем 404.- Схема БД, миграции и UI не менялись.
Проверка
- Новый тест на старом коде падал (409), на новом проходит; полный набор — 13 passed.
- Один из прогонов сразу после перезапуска контейнера дал разовый сбой
test_journal_search_and_filters(total == 0); два повторных полных прогона и отдельный прогон — без ошибок. Связь с правкой не выявлена. - Стенд
ipam_control_006пересобран только по сервисуapp, БД и данные сохранены.