Это старая версия документа!
Содержание
ACCESS_REQUEST в ACCEPTED: требования и активация права
Область: ShariX Open. Обработчик: open_access_request_accepted, тип ACCESS_REQUEST (3), рабочий статус ACCEPTED (321). Опубликованный Python на 28.10.2026 побайтово проверен реальным renderer его Blockly workspace. Схемы отражают встроенную реализацию; выбранная локальная версия и состояние runtime проверяются отдельно.
Назначение и границы
ACCEPTED означает, что запрос одобрен, но permission ещё должна пройти требования и активацию. Обработчик не создаёт отсутствующую Permissions, не считает одобрение заменой документов/проверок и не закрывает Ticket до успешного ответа операции активации. ACCREQ_AUTOACCEPT здесь не проверяется: стадия уже одобрена, а требования действуют независимо от способа принятия PENDING.
Runtime последовательно читает связанную permission, проверяет requirements, запрашивает активацию и только затем CLOSED. Между этими запросами нет одной общей транзакции. Backend повторно проверяет требования внутри канонического activation gate; предварительный ok не разрешает пропустить эту проверку.
BPMN имеют isExecutable=false. Wiki не запускает код: runtime выполняет выбранный проверенный Python из Blockly. End event завершает показанную операцию; defer-узел на первой схеме завершает текущий проход и передаёт ожидание планировщику.
Решения одного прохода (BPMN)
- Не свой статус — запросить удаление локального Ticket и комнаты.
- Permission не найдена — уведомить администраторов, записать
related_permission_missing, ждать поACCESS_REQUEST_INCONSISTENCY_RECHECK_SECONDS. Отсутствующую permission этот handler не создаёт. - Permission есть, но requirements не выполнены — уведомить автора и администраторов, записать
requirements_pendingи назначить тот же именованный повтор. Ticket остаётся вACCEPTED. - Requirements выполнены — запросить активацию. При подтверждённом успехе запросить
CLOSED; после подтверждённого перехода убрать локальный Ticket и комнату. - Операция активации вернула обработанный отрицательный результат — уведомить администраторов, записать
related_permission_inconsistentи отложить на 900 секунд. Это текущая константа Python, а не отдельный параметр окружения.
Связанная permission определяется по ticket_status_id. API читает максимум две записи: отсутствие — 404, несколько — конфликт 409 для ручной проверки данных, а не выбор произвольной permission. 404 этого read-пути может означать также выход Ticket из scope; runtime возвращает «не найдена», не доказывая физического отсутствия permission. Актуальный статус нужно сверить отдельно.
Backend: подготовка действий и повторный gate (BPMN)
GET dbsynce/api/handler/ticket/{ticket_id}/requirements/?model=permission требует capability related.requirements.read и текущий Ticket scope. В этой реализации GET не является чистым чтением: перед оценкой он вызывает ensure_requirement_actions. Канонический evaluator остаётся read-only, а orchestration подготавливает недостающие обязательные черновики документов, попытки RequirementCheck и связанные профильные ST_REQUEST там, где это предусмотрено настройками.
Действия создаются/переиспользуются по доменным правилам. Необязательные требования не навязываются. Отсутствующая CheckDefinition или неподходящая конфигурация очереди не превращаются в успех; для ручных проверок соответствующая очередь должна быть настроена. Platform-level проверка не должна молча попадать в сервисную очередь. Публичный интеграционный порт может подготовить сведения о встрече; это организация, а не результат проверки.
После ok=true runtime запрашивает dbsynce/api/handler/ticket/{ticket_id}/permission/ с действием set_status и status=0. Backend проверяет capability related.permission.status, scope, единственность связи и блокирует строки Ticket/permission. Установка active через совместимый set_status проходит тот же activate_object_if_requirements_met, что и явная activate-операция: повторная подготовка действий и новая оценка обязательных требований. Прямой status=0 не является обходом gate.
При успехе permission получает active, дату проверки и, при наличии assigned_to, соответствующего checked_by. Для METASERVICE-CLIENT и CORP-CLIENT синхронизируются подходящие записи Client/CorpClient с учётом связи Ticket. Permissions остаётся источником права; доменные записи не подменяют её. Backend фиксирует Event и возвращает результат операции. Доступ к конкретным интерфейсам далее определяется их ACL.
Внешний цикл выполнения требований и пробуждение (BPMN)
Пользователь/проверяющий либо настроенный алгоритм выполняет отдельный профильный процесс. Загрузка черновика документа, создание заявки проверки и проверенная версия документа — разные состояния. Подробные решения описаны в IN_PROCESS и DONE. Здесь показана их связь с ожидающим ACCESS_REQUEST, а не исполнение всех действий внутри этого handler.
Когда профильный complete пересчитывает потребителей и требования permission удовлетворены, resume_approved_activation для ACCESS_REQUEST не активирует право скрыто. Он обновляет ревизию Ticket и после commit отправляет ticket.changed текущему handler. Runtime получает scoped актуальный снимок, снимает прежний defer и снова проходит явные Blockly-проверки. При потере сообщения повтор обеспечивают таймер и periodic reconciliation.
Если остаются другие невыполненные требования, completion одной проверки не означает готовность всего права. Отрицательный результат либо незавершённые документы не должны заменяться ручным выставлением active в обход gate.
Ошибки, уведомления и раздельная фиксация
Первоначальный ok и результат активации могут различаться: между запросами меняются данные, требования или scope. Runtime обрабатывает часть отрицательных ответов операции активации как false и ждёт 900 секунд; 401/403/429 и 5xx вызывают исключение и общий processing_error. Ошибки read/requirements API и неожиданные ошибки уведомлений также идут в общий retry. Если проблема постоянна, один таймер её не устраняет: нужно разобрать причину и данные.
404 при переходе в CLOSED запрашивает локальную очистку как для устаревшего scope. Если permission уже активировалась, а закрытие Ticket не удалось, активное право не откатывается. Следующий проход заново проверяет ту же связь и gate; он не должен считаться созданием нового права. Для диагностики различайте статус Ticket, status/check_date/checked_by permission, requirements и Event операции.
Автор уведомляется через текущий legacy helper с локальным Django-поиском пользователя и XMPP-реквизитов. Отсутствие пользователя/реквизитов логируется. Администраторы получают сообщение в MUC-комнату по правилам PENDING: активные METASERVICE-ADMIN, текущий bot и report JID. Это не адресный reviewer API профильных ST_REQUEST и не выдача прав на Ticket. В этих уведомлениях нет durable verification ack; повторные проходы допускают повтор сообщения, а успешный send не доказывает прочтение.
Интервалы и внешнее решение
| Причина | Повтор |
|---|---|
related_permission_missing | ACCESS_REQUEST_INCONSISTENCY_RECHECK_SECONDS |
requirements_pending | ACCESS_REQUEST_INCONSISTENCY_RECHECK_SECONDS |
related_permission_inconsistent | 900 секунд, константа Python |
processing_error | DEFERRED_TICKET_RECHECK_SECONDS |
| Восстановление состава очереди | INTERVAL_TIME_BD_REQ |
Defer хранится в памяти и освобождает worker. Новая authoritative revision снимает ожидание, дубликат того же снимка — нет. Срок означает готовность к проходу, не точное время запуска. При ошибке scoped списка прежний снимок не удаляется как будто backend подтвердил отсутствие Ticket.
Для ручного изменения самого Ticket текущий lifecycle из ACCEPTED разрешает DECLINED либо CLOSED при соответствующих правах; авторство само по себе не даёт права принять/отозвать решение. Перевод Ticket в DECLINED не равен автоматическому удалению уже active permission: соответствующий handler отдельно обрабатывает несогласованность.
Диагностика
Сначала проверьте, какая permission связана с Ticket и единственна ли эта связь, какие requirements реально missing и созданы ли конкретные действия для их выполнения. Затем — состояние внешних проверок, обратный wakeup, результат повторного activation gate и отдельный переход CLOSED. Ручное изменение одного статуса Ticket не заменяет эти операции. Если permission уже active, а последующая оценка выявляет missing, этот handler сам её не деактивирует: он остаётся в ветви ожидания требований. Формулировка уведомления «право пока не активировано» не заменяет чтение фактического status permission; такое расхождение требует отдельного разбора.
Проверенные источники
Git SHA/SHA-256 и параметры моделей закреплены в metadata и documentation BPMN. Код обработчиков при анализе не исполнялся. Изменение Blockly, runtime, API/ACL или доменного gate требует повторного сопоставления, а не только смены хешей.
- sharix-open-handlers-examples / handlers/open_access_request_accepted.py — Git 76e0c693b628ed4a1fa34515a3f8abdff26149bb.
- sharix-open-handlers-examples / generated_handler_blocks/open_access_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/data_parsers.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 / classes/AccessRequestTicket.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.