Покрыть RBAC юнит и интеграционными тестами #29

Problem Statement

Роли определяют, какие действия доступны в десктоп-клиенте, но это поведение покрыто тестами лишь для страниц пользователей. Для страниц ресурсов неизвестно, видят ли модераторы и обычные пользователи правильные кнопки, переживают ли права сквозные переходы и что происходит при протухшей сессии. Любая правка интерфейса может молча сломать доступ целой роли.

Solution

Покрыть матрицу ролей тестами на двух уровнях: юнит/TestFX-тесты видимости и гардов для страниц ресурсов и интеграционные сквозные сценарии входа каждой ролью. Бэкенд не трогаем — достаточно клиентских моков.

User Stories

1. Как администратор, я хочу видеть все кнопки управления ресурсами и пользователями, чтобы выполнять любые действия без обходных путей.
2. Как администратор, я хочу переходить между страницами ресурсов и пользователей, чтобы управлять системой из одного места.
3. Как модератор, я хочу видеть кнопки создания и удаления ресурсов, чтобы выполнять свою работу с контентом.
4. Как модератор, я хочу НЕ видеть кнопки управления пользователями, чтобы случайно не выйти за пределы своих прав.
5. Как модератор, я хочу видеть кнопки правки и удаления в карточке ресурса, чтобы исправлять контент.
6. Как обычный пользователь, я хочу видеть список ресурсов без кнопок управления, чтобы читать контент в режиме только для чтения.
7. Как обычный пользователь, я хочу НЕ видеть раздел пользователей, чтобы не сталкиваться с недоступными экранами.
8. Как обычный пользователь, я хочу скачивать файлы ресурсов, чтобы скачивание оставалось доступным без привилегий.
9. Как гость, я хочу видеть только страницу входа, чтобы не получить доступ к данным без аутентификации.
10. Как гость, я хочу получить понятную ошибку при прямом открытии внутренней страницы, чтобы не видеть пустой экран.
11. Как администратор, я хочу, чтобы сессия переживала переходы между страницами, чтобы не входить заново на каждом экране.
12. Как вышедший пользователь, я хочу, чтобы повторный переход не открывал старые страницы, чтобы выход действительно завершал доступ.
13. Как разработчик, я хочу матрицу ролей в виде параметризованных тестов, чтобы добавление новой кнопки автоматически требовало решения по каждой роли.

Implementation Decisions

• Модули: страницы ресурсов (список, карточка, форма) и интеграционный сьют сквозных сценариев. Страницы пользователей уже покрыты и служат образцом.
• Шов видимости: проверка видимости и занимаемого места кнопок по ролям (пользователь, модератор, администратор, гость) — по одному шву на страницу.
• Шов обработчиков: запрещённые переходы молча игнорируются, без навигации и без ошибки (решение принято в рамках гардов навигации).
• Шов моков: аутентификация и хранилище подменяются клиентскими моками с сидированными учётками каждой роли; живой бэкенд не задействуется.
• Шов интеграции: существующий интеграционный каркас (живые экраны, настоящий навигатор, мок-сервисы).
• Соглашения тестов: ожидание через утилиту асинхронного ожидания (без пауз в коде), русскоязычные названия, Allure-разметка по эпику пользователей и ресурсов, поиск по коду только через ripgrep.
• Словарь строго по глоссарию проекта: роль, гость, блокировка отдельно от удаления, создание пользователя отдельно от регистрации.

Testing Decisions

• Тестируем только внешнее поведение (видимость кнопок, навигацию, тексты ошибок), а не внутреннее устройство контроллеров.
• Два уровня: быстрые изолированные тесты контроллеров и UI-тесты на живых разметках; сквозные ролевые сценарии — на интеграционном уровне.
• Образцы: существующие тесты списка пользователей и кнопок навигации администратора.
• Хороший тест падает ровно по одной причине — изменению прав конкретной роли — и называет эту роль в заголовке.

Out of Scope

• Сидирование живого бэкенда: моков достаточно.
• Саморегистрация: её нет в системе.
• Изменение самих правил доступа: спека фиксирует текущие правила тестами, а не меняет их.
• Гарды обработчиков, учёт блокировки, stale-роль, самодаунгрейд, саморедактирование, гард навигатора: вынесены в тикеты Самовыдача роли через форму ресурса (в ResourceFormController нет RBAC) #89, Гарды обработчиков страниц пользователей (onCreate/onEdit/onDelete без перепроверки роли) #90, Гарды обработчиков списка ресурсов (onCreate/onDelete без перепроверки canModify) #91, Прямые переходы на админские страницы в обход кнопок (гард уровня навигатора) #92, Заблокированный пользователь проходит RBAC (hasRole игнорирует enabled) #93, Роль не перепроверяется после открытия страницы (stale RBAC) #94, Самодаунгрейд и самоблокировка через форму изменения пользователя #95, Саморедактирование пользователя: продуктовое решение #96 — там сначала нужны продуктовые решения.

Further Notes

• Критичная дыра формы ресурса без проверки роли вынесена в тикет Самовыдача роли через форму ресурса (в ResourceFormController нет RBAC) #89 и чинится вне очереди.
• Контрастный кейс модератора (видит ресурсы, не видит пользователей) дублируется в обоих наборах как флагманский.
• Гарды обработчиков страниц пользователей (onCreate/onEdit/onDelete без перепроверки роли) #90 и Гарды обработчиков списка ресурсов (onCreate/onDelete без перепроверки canModify) #91 закрыты по итогам гриля: слой в обработчиках угрозы не закрывает, покрытие даёт связка Самовыдача роли через форму ресурса (в ResourceFormController нет RBAC) #89 (клиент) + Серверный 403 на админских эндпоинтах ресурсов и пользователей #97 (сервер).
• Прямые переходы на админские страницы в обход кнопок (гард уровня навигатора) #92 закрыт как дубликат Самовыдача роли через форму ресурса (в ResourceFormController нет RBAC) #89: один шов (Navigator.goTo), один критерий приёмки.
• Заблокированный пользователь проходит RBAC (hasRole игнорирует enabled) #93 схлопнут в Роль не перепроверяется после открытия страницы (stale RBAC) #94 (клиент) + Серверный 403 на админских эндпоинтах ресурсов и пользователей #97 (сервер): disabled-сессия возможна только mid-session.
• Самодаунгрейд и самоблокировка через форму изменения пользователя #95 закрыт: гард самодаунгрейда/самоблокировки влит (PR fix(пользователи): запрет самодаунгрейда и самоблокировки в форме изменения #99).