- Пользователь попадает из письма по ссылке вида
/trusted-order-info/[id] - На клиенте запрашиваем по id из квери параметров ссылки информацию о доверенном заказе (отдельное api) (id-шник это не айди заказа а уникальный айди связки заказа с текущим доверенным лицом которое привязано к заказу)
- Бекенд у себя чекает разрешения доступа по ссылке (проверяются из хедеров данные авторизованного юзера на предмет соответствия номера на который он регился с номером телефона доверенного лица этого заказа)
- Если пользователь не авторизован бэкенд должен выдать ошибку с дополнительными мета данными
phone- номер телефона который будет вбит в гибридную форму авторизации-регистрации по телефону. После авторизации шлём повторно запрос на инфу о заказе. Сейчас бекенд должен всё успешно вернуть - на ui отображаем верстку. - Если пользователь авторизован и телефон не совпадает с номером который привязан к привязанному доверенному лицу заказа - выдавать ошибку о запрете доступа по ссылке с конкретизацией причины.
- Если пользователь не авторизован бэкенд должен выдать ошибку с дополнительными мета данными
- Отдельный апи ендпоинт на принятие доверенности пользователем (у доверенности меняется статус)
Опционально (требует обсуждения): После подтверждения доверенным лицом доверенности на получение заказа убрать проверку на идентичность номера авторизованного (как и требование к авторизации) - ссылка становится публичной, так как не представляет из себя того что требовало бы идентификации для совершения дополнительных действий.
Кейсы при смене доверенного лица у заказа в процессе пока заказ готовится (в аккаунте автор заказа имеет такую возможность) или отзыве доверенности (заказ получит автор заказа) нужно будет инвалидировать айдишник, ссылка становится невалидной (бэкенд при запросе возвращает ошибку с конкретизацией: если отозвана, сообщение или ключ должен отличаться от случая когда айдишник в принципе не найден (если юзер сам ввёл в урлке любой айди)).