Различия

Показаны различия между двумя версиями страницы.

--- sharixopen:knowledge:scenarios:access_request_accepted [2026/10/28 19:44] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:access_request_accepted [2026/10/31 14:26] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 16: / Строка 16: @@
             "ShariXKnowledgeOpenKnowledgeOperationsRuntimehealth",
             "ShariXKnowledgeScenarios"
+        ],
+        "depends_on": [
+            "ShariXKnowledgeOpenKnowledgeModulesHandlers",
+            "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce"
+        ],
+        "verified_by": [
+            "ShariXKnowledgeVerification"
         ]
     },
@@ Строка 22: / Строка 29: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, dbsynce, tickets",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "ACCESS_REQUEST",
+                "audience_developer",
-                "ACCEPTED",
+                "audience_administrator",
-                "Permissions",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_permissions",
+                "topic_security_permissions",
+                "topic_security_requirements",
+                "access_request",
+                "ticket_accepted",
+                "permissions",
                 "requirements",
-                "BPMN"
+                "activation_gate",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 182: / Строка 203: @@
                 "path": "lib/verification_workflow.py",
                 "sha256": "9fe62f8344d7fd78e5af0ce025c82ba4f7d21759e71f518df1186a1d6a4a0644"
+            },
+            {
+                "repository": "sharix-open-tickets",
+                "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14",
+                "path": "models/ticket.py",
+                "sha256": "4768d9ef47b61bf3ae98bf2749ed142adc477978b44de29177363ba9664baa43"
             }
         ],
@@ Строка 196: / Строка 223: @@
                 "gate": "7bf93bbfeea74a220b533c29f1c8a4ecbc9fb344bafdfbb3673f8dab262a5b49"
             }
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "administrator",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "handlers/permissions",
+                "security/permissions",
+                "security/requirements"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_administrator",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_permissions",
+                "topic_security_permissions",
+                "topic_security_requirements",
+                "access_request",
+                "ticket_accepted",
+                "permissions",
+                "requirements",
+                "activation_gate",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python"
+            ],
+            "registry_document": "ShariXKnowledgeClassification",
+            "state_meaning": "implemented — описана проверенная реализация исходников; серверный runtime отдельно; review — состояние текста"
+        },
+        "editorial_review": {
+            "date": "2026-10-31",
+            "scope": "Конкретизация действий, условий, результатов и диагностики; перечисления; исходные BPMN сохранены",
+            "current_source_records_verified": 25,
+            "original_source_evidence_recheck": "После git fetch все исходные commits/SHA-256 совпали; дополнительные функциональные источники включены в source_evidence",
+            "canonical_regeneration": {
+                "kind": "ticket",
+                "compared_python_paths": [
+                    "handlers/open_access_request_accepted.py",
+                    "generated_handlers/open_access_request_accepted.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false
         }
     },
-    "content_sha256": "2767a7b3e349b0b5b67cebdc15a71e3d547ad8ddce61dd6e2d6c608dc5187df6",
+    "content_sha256": "e17e8ff016aad4b776f21e767b0e75ac98a9d57e86f25c2f3332b6e1c891f787",
     "schema": 1
 }
@@ Строка 205: / Строка 290: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_access_request_accepted'', тип ''ACCESS_REQUEST'' (3), рабочий статус ''ACCEPTED'' (321). Опубликованный Python на 28.10.2026 побайтово проверен реальным renderer его Blockly workspace. Схемы отражают встроенную реализацию; выбранная локальная версия и состояние runtime проверяются отдельно.
+**Назначение:** [[sharixopen:knowledge:classification:materials#scenarij_processa|Сценарий процесса]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]].
+**Для кого:** [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#administrator|Администратор]] · [[sharixopen:knowledge:classification:audiences#podderzhka|Поддержка]] · [[sharixopen:knowledge:classification:audiences#recenzent_i_prijomschik|Рецензент и приёмщик]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]].
+**Темы:** [[sharixopen:knowledge:classification:topics#access_request|Обработчики → ACCESS_REQUEST]] · [[sharixopen:knowledge:classification:topics#polnomochija|Доступ → Полномочия]] · [[sharixopen:knowledge:classification:topics#trebovanija|Доступ → Требования]].
+**Область:** ShariX Open. **Обработчик:** ''open_access_request_accepted'', тип ''ACCESS_REQUEST'' (3), рабочий статус ''ACCEPTED'' (321). 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly; проверены 11 исходников генераторов. Сам обработчик и его внешние действия не запускались. Выбранная версия и работающая установка проверяются отдельно.
 ===== Назначение и границы =====
-''ACCEPTED'' означает, что запрос одобрен, но permission ещё должна пройти требования и активацию. Обработчик не создаёт отсутствующую Permissions, не считает одобрение заменой документов/проверок и не закрывает Ticket до успешного ответа операции активации. ''ACCREQ_AUTOACCEPT'' здесь не проверяется: стадия уже одобрена, а требования действуют независимо от способа принятия PENDING.
+ACCEPTED означает одобренный запрос. Для active permission ещё требуются:
+  * существующая связанная Permissions;
+  * выполненные обязательные требования;
+  * успешный ответ канонической активации.
+Отсутствующая permission этим handler не создаётся. ACCREQ_AUTOACCEPT здесь не проверяется: требования действуют независимо от способа принятия PENDING.
+Порядок runtime:
+  - Прочитать связанную permission.
+  - Проверить requirements.
+  - Запросить активацию с повторным backend gate.
+  - Только после успеха запросить CLOSED.
-Runtime последовательно читает связанную permission, проверяет requirements, запрашивает активацию и только затем ''CLOSED''. Между этими запросами нет одной общей транзакции. Backend повторно проверяет требования внутри канонического activation gate; предварительный ''ok'' не разрешает пропустить эту проверку.
+Общей транзакции этих запросов нет. Предварительный ok не позволяет пропустить повторную оценку внутри активации.
 BPMN имеют ''isExecutable=false''. Wiki не запускает код: runtime выполняет выбранный проверенный Python из Blockly. End event завершает показанную операцию; defer-узел на первой схеме завершает текущий проход и передаёт ожидание планировщику.
@@ Строка 589: / Строка 695: @@
   * Операция активации вернула обработанный отрицательный результат — уведомить администраторов, записать ''related_permission_inconsistent'' и отложить на 900 секунд. Это текущая константа Python, а не отдельный параметр окружения.
-Связанная permission определяется по ''ticket_status_id''. API читает максимум две записи: отсутствие — 404, несколько — конфликт 409 для ручной проверки данных, а не выбор произвольной permission. 404 этого read-пути может означать также выход Ticket из scope; runtime возвращает «не найдена», не доказывая физического отсутствия permission. Актуальный статус нужно сверить отдельно.
+Связь ищется по ticket_status_id с чтением максимум двух записей:
+  * **Нет записи:** 404.
+  * **Несколько записей:** 409, требуется разбор данных.
+  * **Ticket вышел из scope:** read также может вернуть 404.
+По одному 404 нельзя доказать физическое отсутствие permission. Сначала сверить актуальный Ticket и его рабочую область.
 ===== Backend: подготовка действий и повторный gate (BPMN) =====
@@ Строка 784: / Строка 896: @@
 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 проверка не должна молча попадать в сервисную очередь. Публичный интеграционный порт может подготовить сведения о встрече; это организация, а не результат проверки.
+Подготовка действий соблюдает доменные правила:
+  * создаёт или переиспользует необходимые действия;
+  * не навязывает необязательные требования;
+  * не считает отсутствие CheckDefinition успехом;
+  * требует правильно настроенной очереди для ручной проверки;
+  * направляет проверку в очередь, соответствующую её области.
+Необязательный публичный порт может подготовить сведения о встрече. Это организация, а не положительный результат проверки.
 После ''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.
+Успешная активация сохраняет:
+  * active у permission;
+  * дату проверки;
+  * checked_by из assigned_to, когда он задан;
+  * Event операции.
+Для METASERVICE-CLIENT и CORP-CLIENT синхронизируются соответствующие Client/CorpClient с учётом связи Ticket. Источником права остаётся Permissions; доступ к интерфейсам определяется их ACL.
 ===== Внешний цикл выполнения требований и пробуждение (BPMN) =====
@@ Строка 1025: / Строка 1152: @@
 при переходе в ''CLOSED'' запрашивает локальную очистку как для устаревшего scope. Если permission уже активировалась, а закрытие Ticket не удалось, активное право не откатывается. Следующий проход заново проверяет ту же связь и gate; он не должен считаться созданием нового права. Для диагностики различайте статус Ticket, status/check_date/checked_by permission, requirements и Event операции.
-Автор уведомляется через текущий legacy helper с локальным Django-поиском пользователя и XMPP-реквизитов. Отсутствие пользователя/реквизитов логируется. Администраторы получают сообщение в MUC-комнату по правилам [[sharixopen:knowledge:scenarios:access_request_pending|PENDING]]: активные ''METASERVICE-ADMIN'', текущий bot и report JID. Это не адресный reviewer API профильных ST_REQUEST и не выдача прав на Ticket. В этих уведомлениях нет durable verification ack; повторные проходы допускают повтор сообщения, а успешный send не доказывает прочтение.
+Уведомления этой ветви:
+  * **Автор:** legacy helper с локальным Django-поиском пользователя и XMPP-реквизитов; отсутствие получателя логируется.
+  * **Администраторы:** MUC-комната по правилам [[sharixopen:knowledge:scenarios:access_request_pending|PENDING]] — активные METASERVICE-ADMIN, текущий bot и report JID.
+Это не адресный reviewer API профильных ST_REQUEST. Durable verification ack здесь нет, повторные проходы допускают повтор сообщения; send не доказывает прочтения.
 ===== Интервалы и внешнее решение =====
@@ Строка 1040: / Строка 1172: @@
 ===== Диагностика =====
-Сначала проверьте, какая permission связана с Ticket и единственна ли эта связь, какие requirements реально missing и созданы ли конкретные действия для их выполнения. Затем — состояние внешних проверок, обратный wakeup, результат повторного activation gate и отдельный переход CLOSED. Ручное изменение одного статуса Ticket не заменяет эти операции. Если permission уже active, а последующая оценка выявляет missing, этот handler сам её не деактивирует: он остаётся в ветви ожидания требований. Формулировка уведомления «право пока не активировано» не заменяет чтение фактического status permission; такое расхождение требует отдельного разбора.
+Порядок диагностики:
+  - Проверить единственную permission, связанную с Ticket.
+  - Прочитать реально missing requirements и созданные действия.
+  - Проверить состояния внешних проверок и обратный wakeup.
+  - Прочитать результат повторного activation gate.
+  - Отдельно проверить CLOSED и Event операции.
+Если permission уже active, а требования стали missing, текущий handler сам её не деактивирует: он ждёт. Текст уведомления «право пока не активировано» не заменяет чтение фактического status.
 ===== Проверенные источники =====