# Requests Detail View Guide

Статус: актуальный guide по normal UI/API для просмотра заявления.

Этот документ заменяет старое описание detail view, в котором были зафиксированы устаревшие допущения про административные права и смену статуса. В обычном UI заявления теперь работают по strict participant-only rules.

## Что считается участием

Заявление в обычном интерфейсе доступно только:

- автору
- прямым получателям
- пользователям в копии

Администратор сам по себе не получает исключений в обычном UI/API. Повышенные полномочия считаются допустимыми только в Django admin или в отдельном специальном admin-mode, если он будет реализован отдельно.

## Видимость detail view

Detail view и связанные запросы должны подчиняться тем же правилам, что и список:

- автор видит заявление
- прямой получатель видит заявление
- пользователь в копии видит заявление
- посторонний пользователь не видит заявление
- `staff` и `superuser` без участия в заявлении не видят его только из-за роли

Отдельный случай:

- `draft` видит только автор

## Решения по заявлению

Решение (`approve` / `reject`) в normal UI/API может принять только прямой получатель.

Не могут принимать решение:

- автор, если он не добавлен в `recipients`
- пользователь в копии
- посторонний пользователь
- `staff` / `superuser`, если они не являются прямыми получателями

Дополнительные ограничения:

- решение доступно только для `pending`
- по `draft` решение недоступно
- после финального решения второе решение не допускается

## Комментарии

Комментарии в normal UI/API доступны участникам:

- автору
- прямым получателям
- пользователям в копии

Неучастники комментарии не читают и не пишут.

Отдельный случай:

- у `draft` комментарии отключены, потому что черновик принадлежит только автору до отправки

## Что должен показывать фронтенд

Фронтенд не должен пытаться заново вычислять права через role-based эвристики. Источник истины для decision actions приходит из API.

Ожидаемый контракт:

- detail доступен только участнику
- approve/reject показываются только при `status === "pending"` и `can_decide === true`
- для пользователей в копии detail и comments доступны, но approve/reject скрыты
- для `draft` не показываются approve/reject и comments

## Compose и detail связаны

Текущий compose-flow заявлений в normal UI:

- адресация только через пользователей
- прямые получатели находятся в `recipient_ids`
- копия находится в `cc_user_ids`
- черновик можно сохранять неполным
- отправка требует обязательные поля

Следствие для detail view:

- прямой получатель и копия остаются разными ролями
- видимость и право решения нельзя смешивать

## Источники истины

По frontend UI:

- `docs/guides/frontend/README.md`
- `frontend/src/app/requests/page.tsx`

По backend логике:

- `backend/api/v1/requests_app/permissions.py`
- `backend/api/v1/requests_app/views.py`
- `backend/api/v1/requests_app/serializers.py`

## Что больше не считается актуальным

Больше неактуальны утверждения:

- что статус может менять администратор по умолчанию
- что `can_process_requests` достаточно для принятия решения
- что detail view ориентирован на admin-driven workflow

Если понадобится отдельный elevated admin mode для заявлений, он должен быть описан отдельно и не должен подменять этот guide.