Requests Compose UX Guide

Статус: актуальный guide по compose-паттерну формы заявлений.

Этот документ заменяет старое описание recipient picker, в котором были смешаны пользовательские получатели, отделы и старый workflow создания заявлений. Сейчас normal UI формы должен соответствовать текущей backend-логике и общему frontend style guide.

Базовый принцип

Форма создания заявления должна быть похожа на compose-интерфейс электронного письма:

Кому
Копия
Тема
основной текст
вложение
действия формы

Форма не должна выглядеть как техническая админская форма или как длинный список равнозначных полей.

Актуальная адресация

В normal UI используются только пользовательские адресаты:

recipient_ids для прямых получателей
cc_user_ids для копии

В рамках текущего compose-flow не использовать:

department_ids
sent_to_all_department

Если отделы вернутся как отдельный сценарий, это должен быть отдельный UX-flow, а не скрытое расширение текущей compose-формы.

Семантика ролей

Кому и Копия не равны.

Правила:

прямой получатель участвует в маршрутизации решения
пользователь в копии имеет доступ к просмотру, но не принимает решение
фронтенд не должен размывать это различие визуально или логически

Следствие:

Копия не должна выглядеть как второе поле “тоже получатели”
UI не должен создавать впечатление, что все выбранные люди равноправно согласуют заявление

Поведение формы

Черновик

Черновик:

можно сохранить неполным
не требует полного набора обязательных полей
не должен перегружать пользователя ошибками

Отправка

Отправка:

требует хотя бы одного прямого получателя
требует обязательные поля, нужные для конкретного типа заявления
должна использовать нормальный submit-flow, а не локальные role-based исключения

Визуальный контракт

Compose-форма должна придерживаться следующих принципов:

адресные строки сверху
главное поле сообщения занимает визуальный центр формы
служебные поля ниже и спокойнее по весу
footer предсказуем и содержит основные действия: отмена, черновик, отправка

Для dropdown-полей:

если нужен поиск или мультивыбор, использовать shared select-паттерн
не собирать локальные стрелки, раскрытия и chips вручную, если это уже покрывается shared-компонентом

Что больше неактуально

Больше не считаются актуальными идеи:

смешивать отделы и пользователей в одном compose-flow
показывать отправку “всем сотрудникам отдела” как часть обычной формы
трактовать копию как почти тот же список согласующих

Связанные документы

docs/guides/frontend/README.md
docs/guides/frontend/04-PATTERNS.md
docs/guides/REQUESTS_DETAIL_VIEW_GUIDE.md

4.4 KiB Raw Blame History Unescape Escape