Law/context/13_role_flows_test_matrix.md

Матрица User Flow для Тестирования Платформы (CLIENT / LAWYER / ADMIN)

Назначение

Этот файл описывает полный набор пользовательских сценариев для тестирования платформы через веб-интерфейс. Используется как:

1. чеклист ручной приемки,
2. источник для e2e/интеграционных сценариев,
3. карта corner cases по ролям.

Общие правила проверки

1. Все ключевые сценарии проверять через UI (не только по API).
2. Для каждого сценария проверять:
   • видимость данных по роли,
   • корректность уведомлений/непрочитанного,
   • записи в истории статусов/чата,
   • отсутствие утечки служебной/финансовой информации клиенту.
3. Для статусов:
   • важная дата видна клиенту, юристу и администратору,
   • для юриста/администратора это дедлайн текущего статуса,
   • смена статуса логируется вместе с важной датой и комментарием.
4. Для файлов:
   • проверять и успешный сценарий, и ошибки (размер, MIME, предпросмотр, поврежденный файл).

Тестовые роли и данные (рекомендуемые)

1. ADMIN: admin@example.com / admin123
2. LAWYER #1: основной юрист (назначенные заявки)
3. LAWYER #2: другой юрист (для проверок запрета доступа к чужим данным)
4. CLIENT #1: новый клиент (новый номер телефона)
5. CLIENT #2: второй клиент (для проверки изоляции JWT/заявок)

CLIENT (Пользователь / Заказчик)

C01. Просмотр лендинга и создание заявки (happy path)

1. Открыть лендинг.
2. Открыть модальную форму создания заявки.
3. Заполнить:
   • ФИО,
   • телефон,
   • тему,
   • описание.
4. Пройти OTP-подтверждение телефона.
5. Создать заявку.
6. Проверить:
   • выдан уникальный номер заявки,
   • создается запись клиента (client) и связь с заявкой,
   • клиент не видит служебные поля (ставка, стоимость, внутренние ID, ответственные ID, финансовые поля).

C02. Повторный вход в клиентский контур по номеру/OTP

1. На лендинге нажать кнопку перехода к работе с заявкой.
2. Если нет JWT (новое устройство/браузер), пройти OTP.
3. Открыть страницу работы с заявкой.
4. Проверить:
   • доступ только к своим заявкам,
   • после авторизации создается 7-дневный JWT/сессия устройства,
   • повторный вход на том же устройстве не требует OTP до истечения срока.

C03. Переключение между заявками клиента

1. Создать 2+ заявки на один телефон.
2. Открыть клиентский кабинет.
3. Переключаться между заявками в UI.
4. Проверить:
   • отображаются только заявки этого клиента,
   • корректно обновляются статус, чат, файлы, важная дата, уведомления,
   • переход не ломает состояние JWT/авторизации.

C04. Просмотр карточки заявки (видимость данных)

1. Открыть заявку в клиентском кабинете.
2. Проверить, что видны:
   • номер заявки,
   • тема,
   • статус,
   • важная дата (дедлайн),
   • история/маршрут статусов,
   • чат,
   • файлы,
   • запросы дополнительных данных.
3. Проверить, что НЕ видны:
   • ставка юриста,
   • внутренние финансовые поля,
   • служебные ID,
   • служебные комментарии/системная информация, не предназначенная клиенту.

C05. Чат клиент <-> юрист (happy path)

1. Клиент отправляет сообщение юристу.
2. Юрист отвечает.
3. Клиент обновляет/переоткрывает заявку.
4. Проверить:
   • сообщения отображаются в стиле чата,
   • метки времени/даты корректны,
   • непрочитанные индикаторы появляются и сбрасываются после открытия заявки,
   • история сообщений сохраняется.

C06. Загрузка файлов клиентом (happy path)

1. В карточке заявки/чате прикрепить файл.
2. Отправить сообщение с файлом.
3. Проверить:
   • файл загружается,
   • появляется в чате и во вкладке файлов,
   • доступен предпросмотр/скачивание,
   • размер учитывается в лимитах заявки.

C07. Запрос дополнительных данных от юриста (частичное заполнение)

1. Юрист создает Запрос с несколькими полями.
2. Клиент открывает сообщение Запрос.
3. Заполняет часть полей, сохраняет.
4. Повторно открывает запрос и дозаполняет остальное.
5. Проверить:
   • заполненные поля отмечаются и зачеркиваются в чате,
   • незаполненные остаются активными,
   • после полного заполнения запрос сворачивается и меняет цвет/состояние.

C08. file-поле в запросе дополнительных данных

1. Юрист создает запрос с полем типа file.
2. Клиент загружает файл в это поле.
3. Проверить:
   • файл реально загружается как attachment,
   • поле считается заполненным,
   • файл доступен в файлах заявки и в контексте запроса,
   • юрист видит, что запрос выполнен.

C09. Оповещения клиента

1. Юрист меняет статус.
2. Юрист отправляет сообщение.
3. Юрист загружает файл.
4. Клиент открывает кабинет.
5. Проверить:
   • есть визуальные индикаторы новых событий,
   • открытие заявки сбрасывает непрочитанное состояние,
   • важная дата обновляется при смене статуса.

C10. Терминальный статус (завершение заявки)

1. Юрист/админ переводит заявку в терминальный статус.
2. Клиент открывает заявку.
3. Проверить:
   • терминальный статус отображается корректно,
   • маршрут/история статусов содержит финальную запись,
   • важная дата по финальному статусу отображается.

C11. Ошибка загрузки файла (корнер-кейсы)

Проверить UI-реакцию и корректный текст ошибки:

1. Слишком большой файл (>25MB).
2. Превышение суммарного лимита по заявке (>250MB).
3. Обрыв сети/ошибка presigned upload.
4. Неподдерживаемый или некорректный MIME.
5. Проверить:
   • пользователь видит понятную ошибку,
   • UI не зависает,
   • частично неуспешная отправка не ломает чат,
   • дубликаты/битые attachments не создаются.

C12. Слишком длинное сообщение / некорректное сообщение

1. Отправить очень длинный текст (выше backend-лимита, если установлен).
2. Отправить пустое сообщение.
3. Отправить сообщение из пробелов.
4. Проверить:
   • понятная ошибка в UI,
   • ничего лишнего в чат не попадает,
   • состояние формы остается консистентным.

C13. Предпросмотр файлов (валидный / невалидный)

1. Валидный pdf, jpg, mp4, txt.
2. Невалидный PDF (файл с MIME application/pdf, но без %PDF-).
3. .txt с кривым MIME (application/pdf).
4. Проверить:
   • валидные файлы открываются,
   • невалидный PDF дает fallback (понятное сообщение / текстовый предпросмотр),
   • .txt открывается текстом даже при кривом MIME.

C14. Безопасность доступа клиента (изоляция)

1. Открыть чужой номер заявки.
2. Использовать JWT клиента #1 для заявки клиента #2.
3. Попробовать открыть прямые URL файлов чужой заявки.
4. Проверить:
   • доступ запрещен,
   • нет утечки метаданных.

LAWYER (Юрист)

L01. Вход и видимость заявок

1. Войти как юрист.
2. Открыть список заявок.
3. Проверить видимость:
   • свои заявки,
   • неназначенные заявки,
   • отсутствие чужих назначенных заявок.

L02. Claim неназначенной заявки

1. В списке или в канбане выбрать неназначенную заявку.
2. Нажать Взять в работу.
3. Проверить:
   • заявка назначается текущему юристу,
   • в канбане/таблице обновляется исполнитель,
   • claim логируется (audit),
   • другой юрист больше не может ее claim'ить.

L03. Канбан: просмотр и работа с карточками

1. Открыть Канбан.
2. Проверить:
   • группировка по группам статусов,
   • карточки содержат ключевые поля (номер, клиент, тема, дедлайн/важная дата, индикаторы новых сообщений/файлов),
   • горизонтальная прокрутка внутри блока, без растягивания страницы.

L04. Канбан: drag&drop смена статуса (однозначная группа)

1. Перетащить карточку в колонку, где целевая группа сопоставляется с одним статусом.
2. Проверить:
   • статус меняется,
   • важная дата проставляется по умолчанию (+3 дня), если не задана явно,
   • изменение отображается в карточке и в истории статусов.

L05. Канбан: drag&drop в группу с несколькими статусами

1. Перетащить карточку в колонку, где в группе >1 статуса.
2. Проверить:
   • открывается карточка заявки / модалка смены статуса,
   • доступны только статусы соответствующей группы,
   • можно выбрать конкретный статус и важную дату.

L06. Смена статуса из карточки заявки (happy path)

1. Открыть карточку заявки.
2. Нажать кнопку смены статуса.
3. Выбрать новый статус, указать важную дату, добавить комментарий и файл.
4. Отправить.
5. Проверить:
   • статус заявки обновился,
   • важная дата изменилась,
   • запись появилась в истории статусов,
   • комментарий/файл попали в чат.

L07. Терминальный статус (закрытие заявки юристом)

1. Юрист переводит заявку в терминальный статус.
2. Проверить:
   • статус обновлен,
   • заявка считается завершенной в dashboard/метриках,
   • история статусов содержит терминальный этап.

L08. История статусов в модалке смены статуса

1. Открыть модалку смены статуса для заявки с несколькими сменами статусов.
2. Проверить:
   • список прокручивается внутри фиксированного блока,
   • новые записи сверху, старые снизу,
   • видны дата назначения, важная дата, длительность нахождения, комментарий (если есть).

L09. Важные даты (дедлайн) у юриста

1. Сменить статус без указания даты.
2. Проверить автоподстановку +3 дня.
3. Сменить статус с ручной датой.
4. Проверить:
   • дедлайн отображается в карточке заявки,
   • дедлайн отображается в канбане,
   • цвет дедлайна в канбане соответствует сроку.

L10. Чат и файлы юриста

1. Отправка сообщений клиенту.
2. Отправка файлов.
3. Отправка файла+сообщения.
4. Drag&drop файлов в чат.
5. Проверить:
   • сообщения/файлы видит клиент,
   • непрочитанные индикаторы работают,
   • предпросмотр/скачивание работают.

L11. Запрос дополнительных данных (шаблоны)

1. Открыть модалку Запросить.
2. Выбрать существующий шаблон.
3. Проверить автозагрузку полей шаблона в таблицу (без дубликатов).
4. Добавить поле из справочника.
5. Создать новое поле через тот же инпут.
6. Сохранить шаблон:
   • новый,
   • перезапись своего.
7. Проверить:
   • чужой шаблон нельзя перезаписать (UI + backend),
   • badge/tooltip соответствуют статусу шаблона.

L12. Ограничения редактирования заполненных клиентом доп.данных

1. После заполнения клиентом открыть запрос в чате.
2. Проверить, что юрист НЕ может:
   • менять название поля,
   • тип,
   • порядок,
   • удалять заполненное поле.
3. Проверить backend-защиту (через UI негативный сценарий / при попытке сохранить).

L13. Ограничения по правам (чужая заявка)

1. Попробовать открыть/изменить чужую назначенную заявку.
2. Попробовать сменить статус чужой заявки.
3. Попробовать загрузить файл/написать сообщение в чужую заявку.
4. Ожидание: запрет доступа/операции.

L14. Финансовые ограничения

1. Юрист не должен иметь возможность менять запрещенные финансовые поля через CRUD заявки.
2. Юрист не может подтверждать оплату счета (PAID).
3. Проверить UI/API сообщения об ошибке.

ADMIN (Администратор)

A01. Вход и доступ ко всем разделам

1. Войти как администратор.
2. Проверить доступ:
   • Обзор,
   • Канбан,
   • Заявки,
   • Счета,
   • Справочники,
   • availableTables по прямой ссылке.

A02. Справочник пользователей (CRUD)

1. Создать юриста:
   • имя, email, пароль,
   • роль,
   • основная тема,
   • дополнительные темы,
   • ставка по умолчанию,
   • процент,
   • телефон,
   • аватар.
2. Отредактировать пользователя.
3. Деактивировать/активировать.
4. Проверить:
   • данные сохраняются,
   • аватар/инициалы отображаются корректно,
   • роль и RBAC применяются.

A03. Справочники статусов и групп статусов

1. Создать/редактировать группы статусов.
2. Создать/редактировать статусы:
   • группа,
   • терминальность,
   • kind (обычный / счет / оплачено).
3. Проверить:
   • канбан строится по группам,
   • статусы появляются в свободном выборе смены статуса.

A04. Таблицы в справочниках и availableTables

1. Открыть /admin.html?section=availableTables.
2. Включать/выключать таблицы.
3. Проверить:
   • неактивные таблицы исчезают из списка справочников,
   • активные появляются без фронтовой доработки (универсальное отображение),
   • clients видны в справочниках, если таблица активна.

A05. Заявки: полный CRUD и ручное управление

1. Создать заявку вручную.
2. Привязать существующего клиента.
3. Создать нового клиента через форму заявки (если нет в списке).
4. Изменить тему/описание/исполнителя/стоимость.
5. Проверить:
   • client_id корректно проставляется,
   • стоимость заявки видна админу/юристу, скрыта клиенту.

A06. Смена статуса заявки (с важной датой)

1. Открыть карточку заявки.
2. Через модалку смены статуса:
   • выбрать любой статус,
   • указать важную дату,
   • добавить комментарий/файл.
3. Проверить:
   • изменения видны клиенту/юристу/админу,
   • история статусов содержит важную дату и комментарий.

A07. Администратор может корректировать заполненные доп.данные

1. После заполнения клиентом доп.данных открыть запрос.
2. Удалить/изменить заполненную строку (если требуется).
3. Проверить:
   • операция разрешена админу,
   • изменения консистентны.

A08. Счета и оплаты (happy path)

1. Создать счет вручную.
2. Проверить формирование PDF.
3. Перевести в Оплачен.
4. Проверить:
   • дата оплаты проставляется,
   • данные видны в списке счетов,
   • юрист видит свои счета, админ — все.

A09. Billing через статусы

1. Перевести заявку в billing-статус (если используется INVOICE / PAID).
2. Проверить:
   • срабатывает логика счетов/оплаты,
   • сумма/зарплата отражается в дашборде.

A10. Dashboard администратора

Проверить плитки и метрики:

1. Новые / в работе / и др. статусы.
2. Выручка за месяц.
3. Расходы (зарплата юристов) за месяц.
4. Карточки загрузки юристов:
   • активные,
   • новые,
   • закрыто,
   • сумма,
   • зарплата.
5. Модалка статистики юриста:
   • фиксированные хедеры,
   • таблица активных заявок,
   • сумматоры внизу,
   • корректные переходы в карточки заявок.

A11. Безопасность / аудит / доступы

1. Проверка доступа к файлам S3 по ролям.
2. Предпросмотр PDF/файлов через iframe/same-origin.
3. Проверка аудита действий (security audit / audit log).
4. Проверка, что ПДн и финансовые данные не уходят в публичный контур.

A12. Corner cases администратора

1. Ошибки сохранения (невалидные поля, несуществующие ссылки).
2. Одновременное редактирование (refresh после сохранения).
3. Попытка удалить сущность, на которую есть ссылки.
4. Некорректные даты/числа в универсальных формах.
5. Проверить понятные ошибки и отсутствие “битого” состояния UI.

Межролевые интеграционные сценарии (сквозные)

X01. Полный цикл заявки (client -> lawyer -> terminal)

1. Клиент создает заявку.
2. Юрист берет в работу.
3. Юрист ведет чат, запрашивает данные/файлы.
4. Клиент заполняет запрос.
5. Юрист меняет статусы, выставляет важные даты.
6. Юрист завершает заявку терминальным статусом.
7. Проверить весь таймлайн и видимость по ролям.

X02. Цикл со счетом и оплатой

1. Клиент создает заявку.
2. Юрист/админ переводит в статус выставления счета.
3. Админ формирует/подтверждает оплату счета.
4. Проверить:
   • счет виден в заявке и в списке счетов,
   • статус оплаты влияет на финансовые метрики,
   • зарплата юриста считается после Оплачено.

X03. Непрочитанные события и уведомления

1. Создать набор событий: статус, сообщение, файл.
2. Проверить отображение индикаторов:
   • в списках,
   • в канбане,
   • в карточке заявки.
3. Проверить сброс после открытия заявки соответствующей ролью.

X04. Ограничения прав и изоляция

1. CLIENT не видит служебные/финансовые поля.
2. LAWYER не видит/не меняет чужие заявки.
3. LAWYER не подтверждает оплату.
4. LAWYER не редактирует заполненные клиентом доп.данные.
5. ADMIN имеет доступ ко всем данным и операциям.

Corner Cases (общий список для обязательного покрытия)

1. Пустые поля / пробельные значения.
2. Слишком длинные тексты сообщений / комментариев.
3. Файлы:

   • 25MB,

   • превышение 250MB на заявку,
   • невалидный PDF,
   • .txt с кривым MIME.
4. Повторные клики / double-submit.
5. Потеря сети во время upload/send/status-change.
6. Истекший JWT / отсутствие OTP.
7. Конфликт назначения заявки (claim race).
8. Удаление/изменение связанной сущности (клиент/статус/пользователь).
9. Переключение между заявками/разделами при открытых модалках.

Рекомендация по автоматизации (e2e backlog)

Приоритетно выделить в отдельные Playwright-сценарии:

1. public_client_notifications_flow
2. lawyer_status_change_modal_flow (важная дата + комментарий + файл)
3. kanban_multi_status_group_flow (drag&drop -> выбор статуса)
4. admin_finance_billing_dashboard_flow
5. client_file_upload_errors_flow
6. rbac_negative_flows (client/lawyer/admin)