Админка позволяет переименовать фракцию «во всей системе»: PATCH /api/admin/factions/{id} → admin_service.rename_faction меняет factions.name_ru.
При этом seed_reference_data (backend/app/seed/reference_data.py:52-66) для уже существующей фракции безусловно перезаписывает name_ru (и sort_order, expansion_id) значениями из кода. У дополнений (строки 39-47) — то же самое.
Сидинг вызывается не только в миграции 0002:
python -m app.bootstrap → bootstrap() → seed_reference_data, а его запускает backend/entrypoint.shпри каждом старте контейнера (test/prod);
в dev — lifespan main.py при каждом старте/перезагрузке uvicorn.
Сценарий
Админ переименовывает «Орки» в «Орки WAAAGH».
Прод перезапускается: деплой, docker compose up -d после build-push, ребут Pi, рестарт по healthcheck.
После старта фракция снова называется «Орки».
Тест test_admin_rename_faction_system_wide этого не ловит: он проверяет переименование в пределах одного процесса без повторного сидинга.
Варианты решения
В сидинге создавать недостающие записи, но не трогать name_ru существующих (обновлять только служебные поля, если это вообще нужно); или
хранить переименование отдельно (например, флаг/колонка «имя задано админом») и не перетирать его; или
если переименование через админку не нужно — убрать его.
Плюс добавить тест: переименовать → вызвать seed_reference_data → имя сохранилось.
Найдено при сверке документации с кодом.
## Проблема
Админка позволяет переименовать фракцию «во всей системе»: `PATCH /api/admin/factions/{id}` → `admin_service.rename_faction` меняет `factions.name_ru`.
При этом `seed_reference_data` (`backend/app/seed/reference_data.py:52-66`) для **уже существующей** фракции безусловно перезаписывает `name_ru` (и `sort_order`, `expansion_id`) значениями из кода. У дополнений (строки 39-47) — то же самое.
Сидинг вызывается не только в миграции `0002`:
- `python -m app.bootstrap` → `bootstrap()` → `seed_reference_data`, а его запускает `backend/entrypoint.sh` **при каждом старте контейнера** (test/prod);
- в dev — lifespan `main.py` при каждом старте/перезагрузке uvicorn.
## Сценарий
1. Админ переименовывает «Орки» в «Орки WAAAGH».
2. Прод перезапускается: деплой, `docker compose up -d` после `build-push`, ребут Pi, рестарт по healthcheck.
3. После старта фракция снова называется «Орки».
Тест `test_admin_rename_faction_system_wide` этого не ловит: он проверяет переименование в пределах одного процесса без повторного сидинга.
## Варианты решения
- В сидинге создавать недостающие записи, но не трогать `name_ru` существующих (обновлять только служебные поля, если это вообще нужно); **или**
- хранить переименование отдельно (например, флаг/колонка «имя задано админом») и не перетирать его; **или**
- если переименование через админку не нужно — убрать его.
Плюс добавить тест: переименовать → вызвать `seed_reference_data` → имя сохранилось.
Найдено при сверке документации с кодом.
seed_reference_data создаёт недостающие фракции с именем из кода, но у существующих name_ru не трогает: это поле правит админ, источник правды — БД. expansion_id и sort_order синхронизируются как раньше. У дополнений переименования в админке нет — их имена по-прежнему берутся из кода.
Тест: переименовать через API → повторный сидинг (то же, что рестарт) → имя сохранилось.
Тест: сидинг пустой БД дважды — все фракции на месте с именами из кода.
Цена: исправление имени фракции в коде больше не доедет до существующих БД — только через админку или миграцию. Записано в докстринг.
Критерии готовности
Переименование переживает повторный сидинг; новые фракции создаются с именами из кода.
pytest зелёный, новый тест на старом коде падает.
Ветка:issue-72-faction-rename от dev
## План выполнения
1. `seed_reference_data` создаёт недостающие фракции с именем из кода, но у существующих `name_ru` не трогает: это поле правит админ, источник правды — БД. `expansion_id` и `sort_order` синхронизируются как раньше. У дополнений переименования в админке нет — их имена по-прежнему берутся из кода.
2. Тест: переименовать через API → повторный сидинг (то же, что рестарт) → имя сохранилось.
3. Тест: сидинг пустой БД дважды — все фракции на месте с именами из кода.
**Цена:** исправление имени фракции в коде больше не доедет до существующих БД — только через админку или миграцию. Записано в докстринг.
**Критерии готовности**
- Переименование переживает повторный сидинг; новые фракции создаются с именами из кода.
- `pytest` зелёный, новый тест на старом коде падает.
**Ветка:** `issue-72-faction-rename` от `dev`
Итог: сидинг даёт имя из кода только новой фракции; у существующих name_ru не трогает, так что переименование из админки переживает рестарт. Проверки:pytest — 211 passed; тест «переименование → повторный сидинг» падает на старом коде. Статус:Status/In Review Осталось за вами: ревью и мёрж PR — задача закроется автоматически.
Работа выполнена, открыт PR: https://gitea.arseniev.info/NotBigGhost/ForbiddenStarsApp/pulls/94
**Итог:** сидинг даёт имя из кода только новой фракции; у существующих `name_ru` не трогает, так что переименование из админки переживает рестарт.
**Проверки:** `pytest` — 211 passed; тест «переименование → повторный сидинг» падает на старом коде.
**Статус:** `Status/In Review`
**Осталось за вами:** ревью и мёрж PR — задача закроется автоматически.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Проблема
Админка позволяет переименовать фракцию «во всей системе»:
PATCH /api/admin/factions/{id}→admin_service.rename_factionменяетfactions.name_ru.При этом
seed_reference_data(backend/app/seed/reference_data.py:52-66) для уже существующей фракции безусловно перезаписываетname_ru(иsort_order,expansion_id) значениями из кода. У дополнений (строки 39-47) — то же самое.Сидинг вызывается не только в миграции
0002:python -m app.bootstrap→bootstrap()→seed_reference_data, а его запускаетbackend/entrypoint.shпри каждом старте контейнера (test/prod);main.pyпри каждом старте/перезагрузке uvicorn.Сценарий
docker compose up -dпослеbuild-push, ребут Pi, рестарт по healthcheck.Тест
test_admin_rename_faction_system_wideэтого не ловит: он проверяет переименование в пределах одного процесса без повторного сидинга.Варианты решения
name_ruсуществующих (обновлять только служебные поля, если это вообще нужно); илиПлюс добавить тест: переименовать → вызвать
seed_reference_data→ имя сохранилось.Найдено при сверке документации с кодом.
План выполнения
seed_reference_dataсоздаёт недостающие фракции с именем из кода, но у существующихname_ruне трогает: это поле правит админ, источник правды — БД.expansion_idиsort_orderсинхронизируются как раньше. У дополнений переименования в админке нет — их имена по-прежнему берутся из кода.Цена: исправление имени фракции в коде больше не доедет до существующих БД — только через админку или миграцию. Записано в докстринг.
Критерии готовности
pytestзелёный, новый тест на старом коде падает.Ветка:
issue-72-faction-renameотdevРабота выполнена, открыт PR: #94
Итог: сидинг даёт имя из кода только новой фракции; у существующих
name_ruне трогает, так что переименование из админки переживает рестарт.Проверки:
pytest— 211 passed; тест «переименование → повторный сидинг» падает на старом коде.Статус:
Status/In ReviewОсталось за вами: ревью и мёрж PR — задача закроется автоматически.