Ссылка на статус заказа: как гость понимает, что заказ не потерялся

После оформления гость получает короткую ссылку вида /o/<token>. Она открывает текущий статус, состав и сумму заказа без повторного выбора заведения. Такой экран убирает тревожную тишину: человек видит, что заказ существует и меняется по мере работы смены.

Ссылка является ключом доступа. Любой, кому переслали правильный адрес, сможет открыть очищенную гостевую карточку. Поэтому её нельзя считать личным кабинетом или публиковать в открытом чате.

Если читать 30 секунд

• Публичный адрес содержит отдельный случайный токен, а не идентификатор заказа.
• Неверный токен возвращает «не найдено»; одного внутреннего идентификатора заказа для публичного просмотра недостаточно.
• Ответ по токену скрывает имя, контакты доставки, провайдера гостя и свободный комментарий.
• Правильная пересланная ссылка работает у другого человека, потому что токен и есть ключ.
• В текущей реализации у публичного токена нет отдельной даты истечения; это нужно учитывать в правилах хранения ссылки.

Что происходит после оформления

Сервер создаёт для заказа отдельный короткий токен, проверяет его уникальность и возвращает готовый адрес отслеживания. Само значение токена не включается в обычный JSON заказа отдельным полем. Гость видит ссылку и может скопировать её.

При открытии /o/<token> приложение не загружает каталог и не просит снова выбрать стол. Оно запрашивает заказ по токену, показывает текущий этап и ждёт изменения статуса. Если ожидание завершается без события, экран повторяет обычную загрузку, поэтому гость не зависит от одного долгого запроса.

Это отличается от просмотра заказа внутри Telegram или MAX. В обычном сценарии приложение может использовать идентификатор заказа вместе с подтверждённым пользователем мессенджера. Публичная ссылка предназначена для браузерного доступа и проверяется именно по токену.

Значение статусов и обязанности смены разобраны в отдельном сервисном словаре заказа. Здесь важна не последовательность кухни, а контракт доступа к гостевому экрану.

Карта доступа: четыре разных случая

Что есть у человека	Что произойдёт	Что важно объяснить гостю
Полная правильная ссылка /o/<token>	Откроется очищенная карточка соответствующего заказа	Ссылку можно сохранить для проверки статуса
Случайный или неверный токен	Заказ не будет найден	Проверьте, что адрес скопирован целиком
Только внутренний идентификатор заказа	Публичный маршрут не использует его как ключ	Номер или идентификатор нельзя подставлять вместо токена
Пересланная правильная ссылка	Получатель увидит тот же очищенный заказ	Не отправляйте адрес в открытый канал

• Гостевой экран без проверки токена. В публичном демо можно оформить тестовый заказ и увидеть отслеживание статуса. Оно знакомит с интерфейсом, но не подтверждает правила /o/<token>, срок жизни или отзыв ссылки вашей точки.

Есть и пятый практический случай — старая ссылка. В текущем коде публичный токен не имеет отдельного поля срока действия и не истекает автоматически по таймеру. Он работает, пока запись заказа и токен доступны. Не обещайте гостю автоматическое закрытие ссылки через день или после выдачи.

Если бизнесу нужен срок жизни, принудительное отозвание или новая ссылка, это отдельное требование к продукту. Его следует согласовать до запуска. Нельзя описывать несуществующее истечение как готовую защиту.

Какие данные открывает гостевой экран

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

Публичный ответ намеренно не включает имя гостя, его идентификатор и провайдера мессенджера, свободный комментарий, телефон и адрес доставки. В нём также нет самого токена отдельным полем. Интеграционный тест проекта проверяет эти границы.

Санитизация уменьшает объём доступных данных, но не делает ссылку публичной для публикации. Состав заказа, сумма, статус и привязка к столу всё равно относятся к конкретному визиту. Относитесь к адресу как к билету: передавайте тому, кому действительно нужно следить за этим заказом.

Не формулируйте обещание «по ссылке никто не увидит чужой заказ». Точнее сказать так: неверный токен не раскрывает запись, а правильный токен открывает только заказ, к которому привязан, в сокращённом составе полей. Обладатель правильной ссылки получает доступ без дополнительной авторизации.

Почему номер заказа не заменяет токен

Номер на экране нужен гостю и сотруднику для разговора и выдачи. Он может повторяться в разные дни и не задуман как секрет. Идентификатор записи тоже выполняет внутреннюю функцию. Ни один из них не должен становиться публичным паролем.

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

Это правило важно для поддержки. Когда гость сообщает номер заказа, сотрудник не должен конструировать ссылку вручную. Нужно вернуть уже созданный адрес по разрешённому процессу или помочь открыть экран из исходного оформления.

Как гость понимает, что заказ движется

Экран показывает текущий статус и цепочку этапов. При изменении сервер публикует событие, а публичный маршрут проверяет, поменялось ли состояние именно заказа, найденного по токену. Если оно изменилось, интерфейс получает обновлённую очищенную карточку.

Ссылка не ускоряет кухню и не гарантирует время готовности. Она делает текущее состояние видимым. Если смена не обновляет этапы после реальных событий, экран будет честно показывать устаревший статус. Поэтому договорённость сотрудников важнее цвета индикатора.

Для гостя полезны три проверки:

1. после оформления ссылка открывается без повторного ввода данных;
2. номер и состав совпадают с его заказом;
3. изменение этапа появляется без создания новой ссылки.

Если ссылка открывается, но статус долго не меняется, не нужно генерировать новый адрес. Сначала проверьте заказ в рабочей очереди. Если адрес не найден, сверяйте токен целиком, включая регистр и символы.

Правила обращения со ссылкой

Показывайте адрес после успешного создания заказа. До ответа сервера ссылки ещё нет. Не создавайте её из номера стола или номера заказа на клиенте.

Не публикуйте адрес в общем канале. Пересылка конкретному сопровождающему допустима по решению гостя, но открытая группа превращает ключ в общедоступный.

Не обещайте скрытые поля. По токену видны состав и сумма. Если гость считает даже эти данные чувствительными, ссылку не следует пересылать.

Опишите отсутствие автоматического истечения. Для короткого заказа это может быть приемлемой текущей границей, но владелец должен принять её осознанно. Требование отзыва или срока жизни проверяется отдельно.

Для общего браузерного входа и заказа без приложения полезен материал о веб-версии ссылки со стола. Он объясняет вход гостя, а не доступ к уже созданному заказу.

Также сверьте путь гостя после сканирования QR, чтобы команда не смешивала вход в меню с доступом к уже созданному заказу.

Проверка перед запуском

Создайте тестовый заказ в разрешённом контуре и выполните четыре шага карты. Откройте правильную ссылку, измените один статус через рабочую роль, проверьте обновление. Затем замените один символ токена и убедитесь, что заказ не найден.

Отдельно откройте правильную ссылку в другом браузере. Она должна показать очищенный заказ, потому что доступ не связан с локальной сессией. После этого команда лучше понимает, почему адрес нельзя публиковать.

Ссылка полезна, пока остаётся понятным ключом

Гость понимает, что заказ не потерялся, когда сохранённый адрес открывает совпадающий состав и показывает живой статус. Для этого публичный доступ использует отдельный токен и отдаёт сокращённый набор полей.

Честно проговорите границу: правильную ссылку может открыть её обладатель, а автоматического истечения сейчас нет. Если вашей точке нужен отзыв или срок жизни, зафиксируйте это отдельным требованием при обсуждении подключения, не выдавая желаемую защиту за действующую. Такое решение защищает доверие лучше, чем расплывчатое обещание «полной безопасности».