Различия

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

--- sharixopen:knowledge:scenarios:neg_request_declined [2026/10/28 20:05] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:neg_request_declined [2026/10/31 13:21] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 15: / Строка 15: @@
             "ShariXKnowledgeOpenKnowledgeModulesHandlers",
             "ShariXKnowledgeScenarios"
+        ],
+        "depends_on": [
+            "ShariXKnowledgeOpenKnowledgeModulesHandlers",
+            "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce"
+        ],
+        "verified_by": [
+            "ShariXKnowledgeVerification"
         ]
     },
@@ Строка 21: / Строка 28: @@
             "domain": "business_processes",
             "lifecycle": "implemented",
-            "component": "handlers",
+            "component": "handlers_examples, handlers_backend, dbsynce, tickets",
             "parents": [
                 "ShariXKnowledgeScenarios"
             ],
             "terms": [
-                "NEG_REQUEST",
+                "audience_developer",
-                "DECLINED",
+                "audience_support",
-                "Relationship",
+                "audience_reviewer",
-                "grace",
+                "audience_ai",
-                "BPMN"
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_relationships",
+                "topic_architecture_models",
+                "topic_handlers_runtime",
+                "neg_request",
+                "ticket_declined",
+                "relationship",
+                "grace_period",
+                "bpmn",
+                "ticket",
+                "blockly",
+                "generated_python"
             ]
         },
@@ Строка 151: / Строка 170: @@
                 "path": "models/relationship.py",
                 "sha256": "873f27666a7d03b8058958b752d0e69d17d3433daf72f901fa88275cf10f43aa"
+            },
+            {
+                "repository": "sharix-open-tickets",
+                "commit": "fd64704d7d9f01a5ec5b7b89cbc5afe5102b2c14",
+                "path": "models/ticket.py",
+                "sha256": "4768d9ef47b61bf3ae98bf2749ed142adc477978b44de29177363ba9664baa43"
             }
         ],
@@ Строка 164: / Строка 189: @@
                 "cleanup": "4e4c6be9971642c1c093e234f1e254db98cd1c7a2c061045f2ecb0e72e05515a"
             }
+        },
+        "classification": {
+            "schema": "sharix.knowledge.classification.v1",
+            "products": [
+                "sharix_open"
+            ],
+            "audiences": [
+                "developer",
+                "support",
+                "reviewer",
+                "ai"
+            ],
+            "material": "scenario",
+            "topics": [
+                "handlers/relationships",
+                "architecture/models",
+                "handlers/runtime"
+            ],
+            "tag_terms": [
+                "audience_developer",
+                "audience_support",
+                "audience_reviewer",
+                "audience_ai",
+                "product_sharix_open",
+                "material_scenario",
+                "topic_handlers_relationships",
+                "topic_architecture_models",
+                "topic_handlers_runtime",
+                "neg_request",
+                "ticket_declined",
+                "relationship",
+                "grace_period",
+                "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": 20,
+            "original_source_evidence_recheck": "После git fetch все исходные commits/SHA-256 совпали; дополнительные функциональные источники включены в source_evidence",
+            "canonical_regeneration": {
+                "kind": "ticket",
+                "compared_python_paths": [
+                    "handlers/open_neg_request_declined.py",
+                    "generated_handlers/open_neg_request_declined.py"
+                ],
+                "generator_sources_verified": 11,
+                "handler_executed": false
+            },
+            "runtime_checked": false,
+            "correction": "Из NEG_REQUEST DECLINED доступен только CLOSED; прежнее упоминание ACCEPTED исправлено по LIFE_CYCLE_DICT"
         }
     },
-    "content_sha256": "4e4d280bbb63ebb4cea4b6b332b1221caedff60234dbca0757af314f46dea99c",
+    "content_sha256": "d4bcce947bfddf4d46dae21c976d5688e9f0906bab405f6aa067ef051fc2f0e0",
     "schema": 1
 }
@@ Строка 173: / Строка 254: @@
 ~~NOCACHE~~
-**Область:** ShariX Open. **Обработчик:** ''open_neg_request_declined'', тип ''NEG_REQUEST'' (4), рабочий статус ''DECLINED'' (459). Опубликованный Python на 28.10.2026 побайтово совпадает с канонической генерацией Blockly workspace. Выбранная версия конкретного сервера проверяется отдельно.
+**Назначение:** [[sharixopen:knowledge:classification:materials#scenarij_processa|Сценарий процесса]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]].
+**Для кого:** [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#podderzhka|Поддержка]] · [[sharixopen:knowledge:classification:audiences#recenzent_i_prijomschik|Рецензент и приёмщик]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]].
+**Темы:** [[sharixopen:knowledge:classification:topics#neg_request|Обработчики → NEG_REQUEST]] · [[sharixopen:knowledge:classification:topics#vladenie_modeljami|Архитектура → Владение моделями]] · [[sharixopen:knowledge:classification:topics#runtime|Обработчики → Runtime]].
+**Область:** ShariX Open. **Обработчик:** ''open_neg_request_declined'', тип ''NEG_REQUEST'' (4), рабочий статус ''DECLINED'' (459). 31.10.2026 исходники повторно получены из Git. Обе Python-копии совпали с новой канонической генерацией Blockly; проверены 11 исходников генераторов. Сам обработчик и его внешние действия не запускались. Выбранная версия, настройки и доступность подключений конкретной установки проверяются отдельно.
 ===== Назначение и границы =====
-Handler получает уже отклонённый запрос на публичную ''dbsynce.Relationship''. Он не принимает решение об отказе и не переносит на эту модель политику Permissions. После контрольного срока **active Relationship сохраняется, закрывается только Ticket**. Неактивная связь может получить ''status=2'' (deleted), затем Ticket закрывается.
+Handler получает уже отклонённый запрос на публичную dbsynce.Relationship. После контрольного срока:
+  * **Active:** сохранить Relationship и закрыть только Ticket.
+  * **Неактивная:** попробовать soft delete со status=2, затем отдельно закрыть Ticket.
+  * **Связь не найдена при повторном чтении:** удаление становится no-op, после которого возможна попытка CLOSED.
+Решение об отказе принято до этой стадии. Политика Permissions на Relationship не переносится.
 Это отличается от [[sharixopen:knowledge:scenarios:access_request_declined|ACCESS_REQUEST/DECLINED]], который при active permission отправляет ALERT и остаётся ждать разбора. В NEG/DECLINED active-состояние не блокирует закрытие Ticket после срока. Встроенный алгоритм пишет локальную запись журнала о сохранении active, но не вызывает ''notify_admins'' или ''notify_creator''.
-Здесь описана модель взаимоотношений ShariX Open с ''user_who'', ''user_whom'', ''neg_type'', company и ''ticket_status''. Это не отдельная модель ShariX Platform и не отзыв роли или удаление пользователя. ''NEGREQ_AUTOACCEPT'' в этой стадии не используется.
+В публичной модели Relationship используются:
+  * user_who — инициирующая сторона;
+  * user_whom — связанная сторона;
+  * neg_type — тип отношения;
+  * company — контекст компании;
+  * ticket_status — ссылка на сопровождающий Ticket.
+Сохранение active Relationship не является отзывом роли или удалением пользователя. NEGREQ_AUTOACCEPT в этой стадии не используется.
 Просмотрщик не исполняет процесс: BPMN имеют ''isExecutable=false'', runtime запускает выбранный проверенный Python из Blockly. End event завершает показанный проход, а не аннулирует действующие отношения сторон.
@@ Строка 579: / Строка 682: @@
   * Срок наступил, Relationship не active/не найдена — вызвать ''soft_delete_related_relationship'', затем запросить CLOSED. При успешном переходе убрать локальный Ticket и комнату.
-Срок считается от ''Ticket.updated_at'' по ''NEG_REQUEST_DECLINED_CLEANUP_GRACE_DAYS'', а не от created_at и не отдельной даты отказа. Минимум настройки — 0 дней. Новая сохранённая ревизия может сдвинуть контрольную дату. Фактическое значение сервера здесь не предполагается.
+Расчёт контрольного срока:
+  * начало — Ticket.updated_at;
+  * интервал — NEG_REQUEST_DECLINED_CLEANUP_GRACE_DAYS;
+  * минимум настройки — 0 дней;
+  * новая сохранённая ревизия может сдвинуть дату.
+Created_at и отдельная дата отказа вместо updated_at не используются. Фактическое значение сервера здесь не предполагается.
 ===== Ожидание контрольного срока =====
@@ Строка 803: / Строка 913: @@
 Эта схема раскрывает только ветвь предполагаемой **неактивной** связи. Active-ветвь основного алгоритма пропускает soft_delete и закрывает Ticket напрямую.
-Runtime повторно читает связанную Relationship перед soft delete. Отсутствующая связь означает no-op, после которого handler всё равно пробует закрыть Ticket. Если повторное чтение уже показывает active, возникает исключение: устаревшее решение о неактивности не разрешает удаление.
+Повторное чтение перед soft delete:
+  * **Нет связи:** no-op; затем handler пробует CLOSED.
+  * **Уже active:** исключение, старое решение о неактивности не разрешает удаление.
+  * **Неактивная связь существует:** выполнить scoped soft_delete; backend повторяет защиту под lock.
 Для существующей неактивной связи POST ''dbsynce/api/handler/ticket/{ticket_id}/relationship/'' с ''action=soft_delete'' требует ''related.relationship.status'', текущий Ticket scope и единственную связь. Backend блокирует Ticket/Relationship и ещё раз отвергает удаление ''status=0''. Успех сохраняет ''status=2'' и Event. Это soft delete, а не физическое удаление строки.
@@ Строка 809: / Строка 923: @@
 Если связь стала active между проверками, запрос может завершиться ошибкой и общим retry. На следующем актуальном проходе главная active-ветвь сохранит связь и закроет только Ticket при соблюдении срока. Нельзя обходить backend guard ради завершения soft delete.
-Смена статуса Ticket — отдельный scoped запрос. Стрелка между API-пулами показывает последовательность действий handler после ответа, а не прямой серверный вызов одного endpoint другим. После soft delete Ticket может ещё оставаться DECLINED из-за ошибки CLOSED: общего commit этих операций нет. При отсутствии связи runtime может перейти к CLOSED без успешного POST soft_delete.
+Soft delete и CLOSED подтверждать отдельно:
+  * первый запрос меняет статус Relationship и создаёт Event;
+  * второй запрос меняет статус Ticket и создаёт свой Event;
+  * между запросами может возникнуть ошибка;
+  * отсутствующая связь позволяет попытку CLOSED без успешного POST soft_delete.
+Общего commit этих двух запросов нет. После сохранённого status=2 Ticket ещё может оставаться DECLINED. Стрелка между API-пулами описывает последовательность handler, а не прямой вызов одного endpoint другим.
 ===== Внешние действия и события =====
-Пользователь с соответствующим объектным доступом и правом смены статуса может изменить решение через карточку/API. Текущий lifecycle из DECLINED допускает ACCEPTED либо CLOSED. Авторство само по себе не даёт права принять собственный запрос; изменение Ticket не заменяет каноническую активацию Relationship.
+Текущий lifecycle для NEG_REQUEST DECLINED (459) допускает один исход:
+  * **CLOSED (451):** закрыть сопровождающий Ticket при разрешённом доступе.
+Прямого возврата DECLINED → ACCEPTED в коде нет; прежнее упоминание исправлено. Доступ к карточке и право смены статуса проверяются отдельно. Само изменение Ticket не активирует Relationship.
 Канонический backend публикует события после commit. ''ticket.moved'' исключает прежний локальный снимок, при занятом worker — через pending discard; ''ticket.changed'' будит владельца новой стадии, если он существует. Для CLOSED отдельного NEG handler нет. Потерю доставки восстанавливает scoped periodic reconciliation по ''INTERVAL_TIME_BD_REQ''. Ошибка списка не является подтверждением пустой очереди.
@@ Строка 829: / Строка 954: @@
 Read по связи также может вернуть 404 при выходе Ticket из scope; несколько записей дают 409, а не произвольный выбор. Постоянное расхождение требует разбора данных/identity, а не только ожидания таймера.
-Различайте отказ по Ticket и действующий статус Relationship, актуальную ревизию/updated_at, рассчитанный deadline, Event soft delete и отдельный Event CLOSED. Active Relationship вместе с CLOSED Ticket в этом сценарии может быть штатным результатом. Он не доказывает, что handler удалил или деактивировал связь. После неопределённого ответа сначала перечитывают состояния, не повторяя разрушительное бизнес-решение вслепую.
+Порядок диагностики:
+  - Прочитать отдельно Ticket.status и Relationship.status.
+  - Сверить текущие ревизию и updated_at, вычислить deadline.
+  - Для неактивной связи проверить Event soft delete.
+  - Отдельно проверить Event CLOSED.
+  - При неопределённом ответе перечитать сохранённые состояния до повтора.
+Active Relationship вместе с CLOSED Ticket может быть штатным результатом. Это не доказательство удаления или деактивации связи.
 ===== Проверенные источники =====