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 решение недоступно
после финального решения второе решение не допускается

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

Фронтенд не должен пытаться заново вычислять права через 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.

5.1 KiB Raw Blame History Unescape Escape