Phase 1d enhancement: 'Согласования' пункт сайдбара скрыт если у user'а
нет approver/reviewer ролей. Раньше показывался любому authenticated —
оператор без reviewer прав видел queue, кликал и получал пустую
страницу (или 403 если бы пробовал approve).
Visibility rules:
- 'Мои черновики' — auth (maker может быть любой)
- 'Согласования' — auth + (ordinis:schema:reviewer OR ordinis:record:reviewer
OR ordinis:admin super-role) — иначе hidden
- 'Outbox' / 'Webhooks' / 'Аудит' — auth (admin-y но backend не gated
отдельной ролью)
Новый NavItem.reviewerOnly flag — фильтр в visibleSections учитывает
оба flag'а (authRequired + reviewerOnly).
Применено и к desktop Sidebar и к MobileSidebar (DRY refactor — отдельный
task).
Класс имеет два constructor'а (main + test). Без явной @Autowired
аннотации Spring может выбрать no-arg ctor → props=null →
rolesClaimPath() fallback на realm_access.roles несмотря на
env var ORDINIS_AUTH_ROLES_CLAIM=resource_access.ordinis.roles.
Симптом: 403 forbidden_role с message 'Требуется realm role:
ordinis:schema:reviewer' для user с ordinis:admin в
resource_access.ordinis.roles (super-role override не работал
потому что currentRoles() возвращал пустой set из неправильного
claim path).
Fix: @Autowired на main ctor — Spring выбирает его, props
инжектится, rolesClaim читается из env var правильно.
Revert MR !157 (removal). Shared runner pool снова показал queue
contention в часы пик. nstart-tagged выделенный pool обратно — лучше
predictable wait times для CI.
resource_group docker-builds-v2 (для parallel docker builds) остаётся
без изменений — orthogonal к runner tag selection.
User report: token has roles в resource_access.ordinis.roles (client-scoped),
backend WorkflowRoles читал hardcoded realm_access.roles → forbidden_role
для всех reviewer actions.
Backend:
- WorkflowRoles: depends OrdinisAuthProperties → reads via rolesClaim path
(же что ScopeContext). Default realm_access.roles, на staging/prod env
var ORDINIS_AUTH_ROLES_CLAIM=resource_access.ordinis.roles (уже wired
в helm helper).
- Nested claim path resolver — mirror ScopeContext.readClaimByPath
- New super-role ADMIN ('ordinis:admin') — holder автоматически проходит
любой workflow check без явного назначения отдельных ролей. Convenience
для small teams.
Frontend (usePermissions.ts):
- tokenRoles() читает оба claim path (realm_access.roles +
resource_access.ordinis.roles) и объединяет — UI gate работает
независимо от backend config
- hasRole() recognizes 'ordinis:admin' как super-role override
- ROLE_ADMIN exported
Docs:
- docs/operator/rbac.md: добавлен ordinis:admin row, JWT claim path note,
Admin profile updated (super-role vs composite explanation)
Phase 1d enforcement в DraftService.approve()/.reject() требует
realm role 'ordinis:record:reviewer'. Test fixtures используют
JwtTestSupport.signJwt() — добавляем role в JWT для reviewer'ов.
Changes в ApprovalWorkflowE2ETest:
- Новый helper reviewerTokenFor(subject) — internal scope + record:reviewer
- 4 reviewer call sites (bob/dave/julia/leo) → reviewerTokenFor()
- eve-solo (selfApproveBlocked test) тоже → reviewerTokenFor() чтобы
достичь self-approve check, иначе forbidden_role срабатывает раньше
Maker callsites (alice/carol/frank/ivan/kate) остаются на tokenFor()
без reviewer role — backend гейтит только approve/reject методы.
Fix для 4 failures в pipeline 6898:
- happyFlow_submitApprove_recordLiveAndOutboxEvent
- rejectFlow_keepsDraft_noLiveRecord
- selfApproveBlocked_409
- rejectWithoutComment_400
Project uses Altum-style colon-separated realm roles:
- ordinis:client:public / internal / restricted (scope ACL, уже active)
Schema workflow roles (Phase 1d TODO) приводим к той же convention:
- ordinis:schema:reviewer (был ordinis-schema-reviewer)
- ordinis:schema:publisher
- ordinis:schema:maker
Изменения в usePermissions.ts:
- JSDoc обновлён с новой convention
- Constants ROLE_SCHEMA_* для discoverable rename'а в Phase 1d
- TODO comments указывают на constants, не bare strings
Phase 1d (когда подключится backend role check):
1. Uncomment role check в hooks
2. Backend SchemaDraftService.decide() — require role
User feedback (screenshot): 'Approve' остался английским в RU локали +
'Отозвать' улетал на отдельную строку справа из-за ml-auto.
Fix:
- i18n.ts: 'workflow.schemaDraft.actions.approve' default 'Approve' →
'Одобрить'. EN остался 'Approve'.
- SchemaDraftDrawer.tsx: убрал ml-auto на withdraw button. Раньше это
force pushed его в конец строки → flex-wrap отправлял на новую строку
правым краем. Сейчас withdraw сидит сразу после reject в той же
flow-row, с danger color для визуальной distinction. На узком экране
всё ещё wrap'нется естественно (без 'плавающего' alignment).
Browser QA на staging показал что UUID actor'а render'ится raw во многих
местах кроме drawer (MR !158 — там был inline fix):
- /reviews Records tab — column AUTHOR
- /reviews Schemas tab — column AUTHOR
- /audit log — column USER
77ec2cc8-98e3-4d70-8037-94038fcbde67 — нечитаемо для оператора. Тот же
паттерн что я делал в MR !158, теперь shared helper:
src/lib/useUserDisplay.tsx:
- useUserDisplay(uuid) hook — returns { display, isMe, fullId }
- UserCell component — readonly cell с title=fullId tooltip
- Match current user (JWT sub claim) → 'Я • <preferred_username>'
- Other user → short UUID (8 chars) + full в title
- null/undefined → 'anonymous'
Применено:
- reviews.tsx:334,625 — records + schemas table AUTHOR cells
- audit.tsx:476 — USER cell
- SchemaDraftDrawer.tsx — refactor (был inline в MR !158 → теперь shared)
TODO Phase 1d: backend endpoint /admin/users/{sub}/display чтобы и для
не-current-user отображать username.
Sidebar:
- Outbox: бэйдж = outbox.pending (события queued, не отосланы). DLQ
отдельно — alarming но не actionable из бэйджа, видно на /outbox.
- Webhooks: бэйдж = count активных subscriptions (w.active === true).
User feedback: 'вебхуки активные есть а цифры с бэйджем нет'.
Audit log column header:
- 'Scope' → 'Доступ актора' (ru) / 'Actor scope' (en)
- Backend audit_log хранит userScope (claim из JWT актора), НЕ scope
изменённого ресурса. User confusion: 'правки в public были а тут
RESTRICTED' — потому что у пользователя scope-привилегия RESTRICTED.
Уточнённая label убирает путаницу.
- TODO: backend feature — добавить dictionaryScope в AuditEntry чтобы
показать обе ('Актор: RESTRICTED → Ресурс: PUBLIC' — двусторонний
audit trail для compliance).
Два бага в SchemaDraftDrawer (видны на review pending):
1. АВТОР показывал raw UUID (77ec2cc8-98e3-4d70-8037-...). Резолвим:
- Если maker = current user (JWT sub claim) → 'Я • <preferred_username>'
- Иначе → short UUID (первые 8 символов) с full в title attribute
- Стилизация: 'Я' — text-ink (читаемая), чужой — font-mono text-mute
- TODO Phase 1d: backend endpoint для resolve чужих sub → display name
2. Кнопка 'Отозвать' показывалась всем юзерам, не только автору.
- Backend всё равно 403'нет non-maker withdraw — но UI confusion:
reviewer видел кнопку которая всегда fail'ит.
- Gate: показываем только когда auth.user.profile.sub === draft.makerId.
- Reviewer теперь видит чистый action row (Approve / Запросить правки /
Отклонить), без danger-button мимо контекста.
Реальный случай: см. user screenshot на v2.16.x — Reviewer modal с UUID
автора и кнопкой 'Отозвать' справа внизу.
Раньше все jobs pin'ились к runner'ам с tag 'nstart' (выделенный pool).
Runner topology обновлена — все available runner'ы equally provisioned,
сегрегация по тегам больше не нужна.
После remove'а jobs scheduler'ятся на любого available runner'а →
быстрее picks-up в часы пик когда nstart runner был busy. Parallel
docker-* serialize'я по-прежнему работает через resource_group:
docker-builds-v2 (см. .docker_base).
Бэйдж 'На ревью' в sidebar (desktop + mobile) был захардкожен в 0 —
TODO comment ждал cheap /drafts/pending/count endpoint. На самом деле
existing /admin/reviews/pending и /admin/schema-reviews/pending уже
возвращают paged response с totalElements/total в metadata — request
size=1 даёт нужный counter с минимальным payload (~1 строка + 4
metadata field'а).
Новый hook useReviewsBadgeCount():
- Параллельно дёргает обе queue (record + schema)
- Суммирует totalElements (record) + total (schema)
- Полл каждые 60s (lighter чем 30s queue refresh — badge не critical)
- Gated на auth.isAuthenticated (anonymous не должен дёргать admin endpoint'ы)
Sidebar.tsx (оба варианта — desktop + mobile MobileSidebar):
- reviewsCount: 0 → reviews.total
Branch-push pipeline сканировал HEAD~10..HEAD range — включал исторические
commit'ы (например b7e1f12 из MR !154 который сам и привёл к появлению
этого lint'а) → false fail на legacy commits которые уже в main.
MR pipeline использует CI_MERGE_REQUEST_DIFF_BASE_SHA..HEAD — только новые
commit'ы данного MR'а. Это правильный gate: contributor opens MR → lint
валидирует только новый код → fail/pass без noise от старого.
Pipeline 6833 (branch ci/forbid-skip-ci-literal) демонстрирует проблему —
поймал historical commit вместо проверки нашего MR-fix'а.
Pipeline 6834 (MR !155) прошёл — это правильное поведение.
GitLab платформа skip'ает pipeline на любом commit'е чей subject или body
содержит pattern с square brackets вокруг 'skip ci'. Trap: semantic-release
включает release notes из всех commit'ов в release commit body — если хотя
бы один commit имеет этот pattern в subject/body, release tag pipeline
скипается → нет images → нет auto-PR.
Реальный случай: v2.16.1 — commit fix(release): 'remove ... из semantic-
release commit message' содержал паттерн дословно. Pipeline 6831 (v2.16.1
tag) skipped → пришлось trigger через API.
Новый CI job 'commit-msg-lint' (stage: test):
- Запускается на MR pipeline'ах и feature-branch push'ах
- Скипает chore(release) commit'ы (semantic-release auto-bot)
- Для каждого commit'а в range проверяет subject+body на square-bracket
skip-ci pattern
- Fails CI с ясной подсказкой (как переформулировать) при match
RELEASE.md обновлён с разделом 'Skip-ci marker trap': примеры
правильных формулировок (skip-ci marker, the directive, etc) и
escape hatch (manual API trigger).
[skip ci] в commit message skip'ает GitLab pipeline для ВСЕХ ref'ов на
этом SHA — включая tag pipeline. Эффект: semantic-release создаёт v*.*.*
tag, но tag pipeline скипается → images с tag'ом v*-*-*-<sha> не
собираются → propose-prod-image-bump (этот MR) не имеет images для bump.
Confirmed на v2.16.0 (commit bf07d6b): tag pipeline 6814 = skipped,
registry без 'v2-16-0-*' tags → невозможно deploy.
Loop prevention для chore(release) commit'ов работает через releaseRules
('chore': release: false) — semantic-release на этом commit'е detect'ит
'no releasable commits since previous tag' → exit 0 → no new tag → no loop.
Cost: docker-admin-ui ребилдит на каждом chore(release) commit (package.json
+ CHANGELOG.md match frontend-changes path-filter) — ~2 мин wasted CI time,
приемлемо vs broken release flow.
Pipeline 6815 failed instantly с 'could not find expected : at line 625'
— multi-line shell strings внутри script: - | литерального блока YAML
ломали parser потому что continuation lines не были indented к уровню
блока (lines 625, 627-629 в column 0 — YAML видел их как new key).
Fix: собрать message строкой через printf '%b' с явными \n. Однострочные
shell variables — YAML парсит без проблем независимо от содержимого
внутри quotes.
Раньше release tag создавал v2.X.Y, build images, но values-prod.yaml в
ordinis-infra оставался указывать на старый tag (либо unset → fall to
:latest). Это создавало divergence:
- Auto deploy через trigger-deploy-prod использовал runtime
UPSTREAM_IMAGE_TAG = новый tag → правильный deploy.
- Manual deploy через infra repo (helm upgrade -f values-prod.yaml)
использовал static values → старый tag → split-brain ноды через
:latest cache (см. ordinis-infra MR !10 fix).
Новый job 'propose-prod-image-bump':
- Triggers только на tag pipeline (semver v*.*.*).
- Needs все docker-* jobs (images должны быть в registry).
- Clones ordinis-infra, патчит image.tag в values-prod.yaml через awk
с scope-tracking (только image: block, не writer/readApi/etc).
- Commit + push branch + создаёт MR через GitLab API.
- Reviewer approve → merge → infra pipeline auto-катит deploy-prod.
Git становится единственным источником истины: HEAD ordinis-infra main
всегда отражает что задеплоено на prod.
Setup: новая CI variable INFRA_PROJECT_TOKEN (group-level access token
scope: write_repository, api, role: Developer). Без неё job exits early
с подсказкой — pipeline не блокируется (allow_failure: true).
Failed pipeline 6805: /swagger-ui/index.html в test profile вернул 200
(springdoc enabled по умолчанию через ORDINIS_SWAGGER_UI_ENABLED default
true). Это валидно — Swagger render'ит реальную UI page.
Замена: проверяем generic non-API typo path который точно не имеет
controller'а и не SPA-route'д. Покрывает тот же NoResourceFoundException
branch handler'а независимо от springdoc env config.
GlobalExceptionHandler catch-all Exception → 500 ловил NoResourceFoundException
и NoHandlerFoundException. Симптомы на prod:
- /swagger-ui/index.html при disabled springdoc возвращал 500 (UI всё равно
не рендерился, но spring логировал 'Unhandled exception' на каждый запрос —
спамил alerting и затруднял поиск настоящих ошибок).
- GET /api/v1/typo от integrator'ов давал 500 вместо 404, осложняло
debugging без traceId-correlation.
- Любой stale frontend bundle с переименованным endpoint мог триггерить
false-positive incident alerts.
Fix: explicit @ExceptionHandler для обоих exception типов → 404 not_found.
Логирование DEBUG (не WARN/ERROR) — это ожидаемый 404, не аномалия.
Test: SmokeE2ETest.unknownPath_returns404WithNotFoundCode покрывает оба пути
(/api/v1/* и /swagger-ui/*) → 404 + body.code='not_found'.
Per user feedback: «по кнопке что нового должно открываться модальное
окно с изменениями».
UpdateBanner кнопка «Что нового» (т9n key `updateBanner.docs`) ранее
открывала `/docs/` в новой вкладке — generic documentation page, не
contextual для «что именно в этом обновлении».
Теперь — открывает `WhatsNewModal` (тот же modal что показывает 🎁
button в TopBar) — public changelog с release notes сразу.
## Refactor
- **`WhatsNewModal.tsx` (NEW)** — extracted controlled-mode modal с
release notes. Props: `open`, `onClose`. Internal logic читает
changelog, tracks lastSeen в localStorage, на open mark'ает latest
как seen.
- **`WhatsNewButton.tsx`** — refactored: trigger button + use
`WhatsNewModal`. Поведение unchanged (🎁 icon с unread badge → click → modal).
- **`UpdateBanner.tsx`** — replaced `window.open(DOCS_URL)` на
`setWhatsNewOpen(true)` + render `<WhatsNewModal>`. DOCS_URL constant
removed (больше не используется).
## UX intent
Когда update detected:
1. User видит orange banner «Доступна новая версия v2.16.0»
2. Hover «Что нового» button → opens modal
3. User читает release notes (что добавлено, исправлено) ДО reload
4. Click «Обновить» → reload
Раньше «Что нового» вёл к generic docs page — user не знал ЧТО
изменилось, только что update есть. Modal даёт structured answer.
## Test plan
- [x] `pnpm tsc --noEmit` clean
- [x] `pnpm build` clean
- [x] `pnpm vitest run useChangelog.test` — 11/11 pass (parser logic
unchanged)
- [ ] Manual: симулировать update banner (mock useAppVersion
`updateAvailable=true`), click «Что нового» → modal opens
- [ ] Manual: 🎁 button в TopBar также opens same modal
- [ ] Manual: close modal → red dot disappears на 🎁 button
(localStorage updated)
Александр Зимин