Назначение: Контракт. Продукт: ShariX Open · Общий компонент.

Для кого: Разработчик · Интегратор · Рецензент и приёмщик · Нейросеть.

Темы: Заказы → Модель · Заказы → Жизненный цикл · Архитектура → Владение моделями.

Эта страница помогает выбрать данные и операцию при доработке заказа в ShariX Open. Она описывает проверенный исходный код; состояние конкретной установленной базы проверяется отдельно.

В тексте Order означает заказ; фактическое имя общей Django-модели — Orders. ID Orders, ID Ticket и ID локальной записи принадлежат разным таблицам. При вызове API нужно передавать идентификатор требуемого объекта, а не другое число, случайно совпавшее с ним в тестовых данных.

Поля участников заказа:

• client — клиентский профиль.
• corp_client — корпоративный заказчик.
• created_by — пользователь, создавший заказ.
• provider — предложение исполнителя, а не просто его учётная запись.
• receiver — получатель услуги.
• receiver_name — имя получателя, сохранённое в самом заказе.
• receiver_phone — телефон получателя, сохранённый в самом заказе.

Создатель, плательщик/заказчик и получатель могут быть разными лицами.

Например, при оформлении услуги для другого человека нельзя заменить created_by на receiver ради отображения имени в карточке: это изменит смысл авторства. Нужно найти поле отображаемого получателя и сохранить действующее основание доступа. Связи предложений и участников описаны в Backend/dbsynce.

Связь и отображение статуса:

• Orders.ticket_status — ссылка на Ticket.
• Orders.status — отражение статуса для потребителей заказа.
• sync_status_from_ticket — вызывается при сохранении Orders.
• get_status_display — при наличии Ticket читает его состояние.

Отдельная запись числа в Orders.status не заменяет переход Ticket и не подтверждает запуск нужного обработчика.

Для пользовательского действия над заказом точка входа — dbsynce.lib.order_actions.perform_order_action. Дальнейшая проверка зависит от выбранного действия: кто его выполняет, допустимо ли текущее состояние, не изменились ли значимые условия. Нельзя считать список кнопок самостоятельной проверкой прав.

Нижележащая tickets.utils.change_ticket_status проверяет допустимость перехода и создаёт Event, но сама не проверяет права пользователя на объект. Поэтому её нельзя подставлять вместо order action в новую публичную view. Проверка actor и объекта должна остаться в вызывающем предметном слое.

В API операция create_order_from_payload выполняет внутри transaction.atomic следующие шаги:

1. Сохраняет Orders и получает pk из БД.
2. Создаёт SERVICE_REQUEST Ticket.
3. Связывает Ticket с заказом.
4. Вызывает порт инициализации исполнения.

У режима draft начальный статус TEMPLATE; у place — BOOKED. Если режим не передан, текущая нормализация выбирает place. Для категории подписки операция принудительно использует place.

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

PROCESS — состояние всего SERVICE_REQUEST, а Stage — отдельный этап исполнения. В проверенном API инициализация исполнения вызывается уже при создании заказа. Поэтому неверно описывать переход в PROCESS как обязательный момент первого создания всех этапов.

Возможны разные результаты инициализации:

• Runtime-порт не зарегистрирован: configured=false и stage_count=0.
• Адаптер зарегистрирован, но политика услуги не настроена: локальная инициализация возвращает отсутствие настроенного исполнения.

Наличие самого вызова не доказывает, что у каждого заказа созданы Stage.

Концепция разделения ответственности — поясняющее описание. Состояние всего заказа отвечает на вопрос, где находится услуга в жизненном цикле; этап отвечает на вопрос, выполнена ли конкретная часть работы. Нажатие кнопки не обязано становиться этапом, а завершение одного этапа не означает безусловного завершения заказа. Реальные ограничения проверяют в runtime и контракте Stage.

Сигналы tickets планируют XMPP-событие ticket.changed после commit. При канонической смене статуса прежнему обработчику также адресуется ticket.moved. Получатель сверяет сохранённое состояние; отправка сигнала не является подтверждением, что удалённый обработчик уже выполнил работу.

При разборе сбоя проверяют отдельно:

• сохранённый Ticket и заказ;
• Event перехода;
• факт доставки и обработки;
• видимый результат.

Ошибку сети после commit нельзя описывать как автоматический откат заказа.

Здесь описаны открытые модели и операции ShariX Open. Закрытый конструктор и другие отдельно лицензируемые компоненты могут подключаться через публичные границы, но их внутренние модели сюда не переносятся. Перечень и контакт — владение моделями. Если меняется общий модуль, после публикации передают изменение ответственному Platform по порядку shared-изменений; внутреннюю часть проверяют по intrawiki.

Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение версии, данных или выполненного запроса на сервере.

• sharix-open-backend: models/orders.py.
• sharix-open-backend: lib/open_order_api.py.
• sharix-open-backend: lib/order_actions.py.
• sharix-open-backend: lib/integration_ports.py.
• sharix-open-backend: lib/ticket_gen.py.
• sharix-open-tickets: models/ticket.py.
• sharix-open-tickets: signals.py.
• sharix-open-webservice-running: models/execution.py.
• sharix-open-webservice-running: services/order_execution.py.
• sharix-open-tickets: utils.py.