Назначение: Указатель раздела. Продукт: ShariX Open.

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

Темы: База знаний → Навигация · Обработчики → Runtime · Заказы → Жизненный цикл.

Это указатель описаний процессов и их BPMN. Он помогает выбрать сценарий по объекту, типу заявки и текущему состоянию. Подробный алгоритм, исходные версии и известные ограничения находятся на странице соответствующей операции; наличие ссылки здесь не означает, что процесс повторно проверен на вашей установке.

1. Определить объект: общий заказ, Ticket, документ или локальный этап исполнения. ID этих объектов не взаимозаменяемы.
2. Для Ticket установить ticket_type и сохранённый статус, а для handler — его фактически выбранную версию.
3. Найти соответствующий тип и стадию в таблицах ниже.
4. Прочитать условия входа, внешних участников, API/права, таймеры и границы отказов.
5. Сопоставить указанные commits с исследуемой версией. При расхождении читать актуальный код и уточнять описание.

Например, NEW и ASSIGNED в ST_REQUEST обслуживают разные handlers. Если backend уже хранит ASSIGNED, старое ожидание NEW не является текущим бизнес-состоянием заявки.

• Создание заказа через API — запрос, Orders и Ticket, транзакция, ответ, предупреждения и события после commit. HTML-форма имеет отдельный путь и проверяется отдельно.
• Заявка на партнёрский кабинет — действия заявителя, условия доступа, создаваемые запросы и результат рассмотрения.
• Заказ, Ticket и PROCESS — какую роль играет каждый объект и где находится его состояние.

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

• установку и версию исходников;
• роль инициатора и допустимый объект;
• исходное состояние и значимые настройки;
• выполненное действие и ответ;
• сохранённый результат;
• полученное событие/внешнее действие, если они требуются;
• видимый результат для пользователя;
• точку остановки и непроверенную часть.

Нельзя считать доставленное уведомление доказательством завершения услуги, а потерю HTTP-ответа — доказательством отката. Если исход записи неизвестен, сначала проверяют фактическое состояние; повтор может создать второй объект.

Для затронутого процесса определить ожидаемый результат при следующих условиях:

• недостаточные права пользователя или handler capability;
• чужой объект либо другая область метасервиса;
• неподходящий или уже изменившийся статус;
• повторный запрос или повторное событие;
• устаревшая версия данных;
• недоступная интеграция;
• истечение срока;
• перезапуск с потерей локального состояния ожидания.

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

• Дорожки и участники показывают распределение ответственности.
• Условие шлюза показывает, почему выбран следующий путь.
• Таймер обозначает ожидание по указанному источнику времени; реальное значение настройки проверяют отдельно.
• Сообщение показывает внешнее взаимодействие, которое нельзя вывести только из локального Blockly-блока.
• Ветвь ошибки может обозначать предусмотренный отказ, а не найденный дефект.

Схемы в Wiki описательные и не запускают код. Связь Blockly → Python и устройство исполнения описаны в обработчиках. Текст и схема должны относиться к одним изученным источникам.

Следующие страницы задают разбор связанных действий и критериев проверки; доступность полного пути устанавливают по конкретному коду и установке:

• Общие сценарии проверки архитектуры.
• Получение и передача документов.
• Дополнительная услуга из этапа.
• Подтверждение допуска исполнителя.

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

Опубликованные встроенные обработчики разобраны по одному: алгоритм, внешние участники, таймеры и границы доменных действий.

CLOSED — терминальная стадия; отдельного встроенного open_st_request_closed в текущем каталоге нет. Историческое имя open_st_request_dublicate не является второй доступной реализацией DUPLICATE.

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

• sharix-open-handlers-examples: catalog.py.
• sharix-open-handlers-backend: core/blockly_runtime.py.
• sharix-open-tickets: signals.py.
• sharix-open-tickets: api/views/handler_workflow.py.
• sharix-open-backend: lib/open_order_api.py.
• sharix-open-backend: lib/ticket_gen.py.