mirror of
https://gitverse.ru/kpa39l/vesti.git
synced 2026-09-29 18:05:03 +00:00
kpa39l
f890ad71f1
- _fetch_candidates: статус группы = доминирующий (new>rejected>published), а не первого поста → при group_by=date группа «Ранее на этой неделе» больше не выглядит опубликованной (openchange fix-date-group-status) - base.html: padding-top 1.5rem→4.5rem — заголовок не перекрывается fixed-top меню - published.html: ID поста на карточках (#N · направление) - AGENT.MD: бэкапы автоматические по крону, вручную не запускать
52 lines
3.9 KiB
Markdown
52 lines
3.9 KiB
Markdown
## Why
|
||
|
||
При переключении группировки списка кандидатов на «дата» (`/candidates?group_by=date`)
|
||
статусные бейджи групп и правая панель вводят в заблуждение: часть групп
|
||
(например, «Ранее на этой неделе», 52 поста) не получает бейджа статуса,
|
||
а выбранный пост в правой панели может выглядеть как уже «опубликованный»
|
||
(кнопка «Опубликовать» скрыта), хотя это — обычный кандидат.
|
||
|
||
Причина: в `_fetch_candidates` статус группы вычисляется как
|
||
`items[0]["status"]` — статус ПЕРВОГО (свежайшего) поста в группе.
|
||
При группировке по дате первым в группе оказывается самый свежий пост,
|
||
который может быть уже опубликованным или отклонённым, хотя вся остальная
|
||
группа — новые кандидаты. Шаблон `candidates.html` рисует бейдж только для
|
||
`new`/`rejected`, поэтому группа с первым published-постом выглядит «без
|
||
статуса» (как опубликованная), а у selected-published поста скрыта кнопка
|
||
«Опубликовать».
|
||
|
||
Наблюдаемый симптом пользователя: «при переключении на сортировку по дате
|
||
все кандидаты становятся отмеченными опубликовано и источник „Дед в АйТи“».
|
||
|
||
## What Changes
|
||
|
||
- В `web/app.py` (`_fetch_candidates`): статус группы считать не по первому
|
||
посту, а как ДОМИНИРУЮЩИЙ статус внутри группы:
|
||
- если в группе есть `new` → статус группы `new`;
|
||
- иначе если есть `rejected` → `rejected`;
|
||
- иначе если есть `published` → `published`;
|
||
- иначе — статус первого поста (запасной вариант).
|
||
- Шаблон `candidates.html` остаётся без изменений (для `published` бейдж не
|
||
рисуется — это корректно: опубликованные не показываются в кандидатах как
|
||
активные). Исправление логики устраняет и ложный «published»-вид группы, и
|
||
неправильный вид правой панели для не-публикованных постов.
|
||
- При `group_by=date` группа «Ранее на этой неделе» с 52 постами (51 new +
|
||
1 published) теперь получит бейдж «новые».
|
||
|
||
## Why Not
|
||
|
||
- Не менять сортировку постов внутри группы на статус: это сломает ожидание
|
||
«свежие сверху» для группировки по дате.
|
||
- Не прятать published-посты из date-группировки полностью: пользователь
|
||
должен видеть, что именно опубликовано в этот период.
|
||
- Минимальная правка в одном месте (`_fetch_candidates`) — не трогаем шаблон
|
||
и не меняем схему БД.
|
||
|
||
## Impact
|
||
|
||
- Файл: `web/app.py`, функция `_fetch_candidates`, блок вычисления
|
||
`"status"` группы.
|
||
- Данные: без миграций БД.
|
||
- Сервис: `vesti-web` (:8400) — требуется перезапуск.
|
||
- Rollback: откатить правку в `_fetch_candidates` и перезапустить сервис.
|