Содержание
NEG_REQUEST в ACCEPTED: активация Relationship и срок закрытия
Назначение: Сценарий процесса. Продукт: ShariX Open.
Для кого: Разработчик · Поддержка · Рецензент и приёмщик · Нейросеть.
Темы: Обработчики → NEG_REQUEST · Доступ → Требования.
Область: ShariX Open. Обработчик: open_neg_request_accepted, тип NEG_REQUEST (4), рабочий статус ACCEPTED (421). 31.10.2026 опубликованные исходники повторно получены из Git. Обе Python-копии заново сопоставлены с результатом генерации Blockly; проверены 11 исходников генераторов. Сам handler не исполнялся. Выбранную версию, конфигурацию и внешние подключения сервера проверяют отдельно.
Назначение и границы
Handler сопровождает уже одобренный запрос на публичную dbsynce.Relationship: проверяет обязательные требования, запрашивает активацию и затем ждёт контрольного срока закрытия Ticket. Он не создаёт отсутствующую связь и не считает ACCEPTED доказательством выполненных requirements. NEGREQ_AUTOACCEPT здесь не проверяется.
Relationship этого сценария — направленная запись публичного dbsynce со следующими данными:
user_who— инициирующая сторона;user_whom— связанная сторона;neg_type— тип отношения;company— контекст компании, если задан;ticket_status— ссылка на сопровождающий Ticket.
Это не Permissions и не универсальная выдача LDAP-роли. Отдельные модели взаимоотношений Platform здесь не рассматриваются; permission-specific синхронизация Client/CorpClient из ACCESS_REQUEST в этой ветви не выполняется.
Ключевое отличие от ACCESS_REQUEST/ACCEPTED: Relationship активируется до ожидания срока закрытия. Контрольный срок относится к Ticket и не задерживает саму активацию, если requirements и backend gate успешно пройдены.
BPMN имеют isExecutable=false. Просмотрщик Wiki не исполняет обработчик: runtime запускает выбранный проверенный Python, сгенерированный из Blockly. End event завершает показанную операцию; defer-узлы заканчивают проход и передают ожидание планировщику.
Решения одного прохода (BPMN)
- Чужой статус — запросить удаление локального Ticket и комнаты.
- Relationship не найдена — ALERT администраторам, локальная причина
related_relationship_missing, повтор поNEG_REQUEST_INCONSISTENCY_RECHECK_SECONDS. В журнал defer в этой ветви передаётся строкаrelated_relationship_inconsistent; она не переписывает сохранённую локальную причину. - Requirements не выполнены — уведомить автора и администраторов, записать
requirements_pendingи назначить тот же именованный повтор. Связь этим handler не активируется, Ticket остаётся ACCEPTED. - Requirements выполнены — запросить каноническую активацию Relationship. Обработанный отрицательный результат вызывает ALERT,
related_relationship_inconsistentи повтор через 900 секунд; это текущая константа Python. - Активация подтверждена — проверить срок от
Ticket.updated_at. При наступившем сроке запросить CLOSED, затем убрать локальный Ticket/комнату. До наступления срока —neg_request_close_graceи короткий defer.
В workspace используется typed block sx_activate_related_relationship. Его каноническое раскрытие в Python включает guard неуспешной активации с ALERT/900-секундным повтором; этот исход показан на схеме и не пропущен при описании одного action-блока.
Требования и backend gate (BPMN)
Связь читается через dbsynce/api/handler/ticket/{ticket_id}/relationship/ по ticket_status_id. Требуются handler identity, актуальный scope и related.relationship.read. В отличие от рассмотренного расхождения PENDING, каталог этой стадии объявляет read/status для Relationship. 404 read может означать отсутствие связи либо выход Ticket из scope; несколько связанных записей дают конфликт 409, а не выбор одной наугад.
GET requirements/?model=relationship требует related.requirements.read. Перед read-only оценкой он вызывает ensure_requirement_actions: подготавливает/переиспользует обязательные черновики документов и попытки проверок с соответствующими ST_REQUEST там, где это предусмотрено настройками. Наличие запроса проверки не означает, что он пройден. Необязательные требования не навязываются, а отсутствие определения/очереди не превращается в успех.
При первоначальном ok runtime запрашивает relationship/ с action=set_status, status=0. Backend проверяет related.relationship.status, scope и единственность связи, блокирует Ticket/Relationship и снова запускает канонический activate_object_if_requirements_met. Прямой status=0 проходит тот же gate; первоначальный ok не является разрешением обойти повторную оценку. При успехе сохраняются active и связь с Ticket, затем Event операции.
У этого процесса три самостоятельных результата:
- активация Relationship;
- доставка уведомлений;
- перевод Ticket в CLOSED.
Ошибка последующего закрытия Ticket не откатывает уже active Relationship. Если требования позднее не выполнены, текущий handler сам не деактивирует связь: он остаётся в ветви ожидания. Состояние нужно читать в сохранённой Relationship, а не выводить из текста уведомления.
Контрольный срок и внешний цикл требований (BPMN)
Для контрольного срока используются:
- NEG_REQUEST_DECLINED_CLEANUP_GRACE_DAYS — точное имя настройки даже в ACCEPTED; слово DECLINED не меняет её фактическое использование;
Ticket.updated_at— начало отсчёта;updated_at + grace_days— конечная граница, минимум настройки 0 дней;- минимум этой границы и
now + DEFERRED_TICKET_RECHECK_SECONDS— следующий локальный defer; neg_request_close_grace— локальная причина и строка журнала.
До истечения grace Relationship уже может быть active, а Ticket оставаться ACCEPTED. При каждом повторном проходе Python снова выполняет поиск, проверку requirements и запрос активации прежде, чем дойти до проверки срока. Здесь нет marker «активировать только один раз», аналогичного completed у профильных ST_REQUEST. Нельзя считать повторный Event новой заявкой на взаимоотношение.
Новая authoritative revision может снять defer и изменить контрольную дату; дубликат того же снимка — нет. Если updated_at отсутствует/не разбирается, проверка возраста возвращает false, а helper срока не устанавливает корректный defer; такие данные требуют разбора, а не признания grace истёкшим.
Внешний процесс документов/RequirementCheck раскрыт в ST_REQUEST/IN_PROCESS и DONE. Его complete пересчитывает потребителей. Для NEG_REQUEST удовлетворение требований вызывает resume_approved_activation, который обновляет ревизию Ticket и после commit будит текущий handler через ticket.changed. Активация остаётся явной в Blockly текущего handler, а не скрыто выполняется этим callback. Если требования ещё не удовлетворены, ожидание продолжается.
Ошибки и уведомления
Обработанные отрицательные ответы операции активации дают false и ветвь 900 секунд; 401/403/429, 5xx и ошибки read/requirements API вызывают исключение и общий processing_error с DEFERRED_TICKET_RECHECK_SECONDS. Изменение данных между первоначальной оценкой и повторным gate может объяснять разные результаты. Таймер сам по себе не исправляет постоянную ошибку данных или scope.
404 при запросе CLOSED запрашивает локальную очистку как при устаревшем контексте. Иные ошибки закрытия не отменяют уже сохранённый active. После commit канонический backend отправляет события смены владельца; Ticket в CLOSED больше не имеет отдельного NEG handler. Потерю событий восстанавливает scoped periodic reconciliation.
Автор уведомляется через текущий local-Django helper и его XMPP-реквизиты. Администраторы получают MUC-сообщение по общим правилам NEG/PENDING. В этих уведомлениях нет durable verification ack, повторные проходы могут повторять сообщения; send не доказывает прочтение и не выдаёт доступ к Ticket.
Настройки и диагностика
| Состояние | Повтор |
|---|---|
| Relationship отсутствует | NEG_REQUEST_INCONSISTENCY_RECHECK_SECONDS; локально related_relationship_missing, журнал related_relationship_inconsistent |
| Требования не выполнены | NEG_REQUEST_INCONSISTENCY_RECHECK_SECONDS, requirements_pending |
| Активация не подтверждена | 900 секунд, related_relationship_inconsistent |
| Active, но срок закрытия ещё не истёк | NEG_REQUEST_DECLINED_CLEANUP_GRACE_DAYS от updated_at; короткий defer, neg_request_close_grace |
| Общее исключение | DEFERRED_TICKET_RECHECK_SECONDS, processing_error |
| Сверка состава | INTERVAL_TIME_BD_REQ |
Defer хранится в памяти и освобождает worker. При рестарте runtime заново получает актуальный снимок. Ошибку scoped списка нельзя считать подтверждённой пустой очередью.
При диагностике записать отдельно:
- одобрение и текущий статус Ticket;
- фактическую Relationship, её направление и тип;
- результат requirements;
- ответ операции активации;
- актуальный updated_at и рассчитанный срок;
- результат отдельного перехода CLOSED.
Active при ACCEPTED до контрольного срока может быть штатным. Допустимые переходы ACCEPTED → DECLINED/CLOSED не подменяют доменное действие над Relationship.
Проверенные источники
Git SHA/SHA-256 и параметры моделей закреплены в metadata и documentation BPMN. Код handler при анализе не исполнялся; изменение источников требует повторного сопоставления.
- sharix-open-handlers-examples / handlers/open_neg_request_accepted.py — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
- sharix-open-handlers-examples / generated_handler_blocks/open_neg_request_accepted.json — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
- sharix-open-handlers-examples / catalog.py — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
- sharix-open-handlers-backend / core/blockly_runtime.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / core/handler_operations.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / core/ejabberd_muc.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / core/requesters.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / ticket_blockly_codegen.py — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-handlers-backend / ticket_codegen_contract.json — Git 50baf376e224d915a87d63240f3f339b3dda9afa.
- sharix-open-tickets / lib/tickets.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / api/views/handler_workflow.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / api/handler_auth.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / utils.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / views/ticket_detail.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / signals.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-tickets / services/handler_wakeup.py — Git fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14.
- sharix-open-backend / apiviews/handler_workflow.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/activation.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/requirement_actions.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/requirement_checks.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/document_drafts.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / lib/verification_workflow.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.
- sharix-open-backend / models/relationship.py — Git 778a3280cee115ba0efe3fdff7b0e708b0c10093.