| Следующая версия | Предыдущая версия |
| sharixopen:knowledge:scenarios:neg_request_accepted [2026/10/28 20:01] – [sharixknowledge] approved package sx_knowledge_api_open | sharixopen:knowledge:scenarios:neg_request_accepted [2026/10/31 11:25] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open |
|---|
| "domain": "business_processes", | "domain": "business_processes", |
| "lifecycle": "implemented", | "lifecycle": "implemented", |
| "component": "handlers", | "component": "handlers_examples, handlers_backend, dbsynce", |
| "parents": [ | "parents": [ |
| "ShariXKnowledgeScenarios" | "ShariXKnowledgeScenarios" |
| ], | ], |
| "terms": [ | "terms": [ |
| "NEG_REQUEST", | "audience_developer", |
| "ACCEPTED", | "audience_support", |
| "Relationship", | "audience_reviewer", |
| | "audience_ai", |
| | "product_sharix_open", |
| | "material_scenario", |
| | "topic_handlers_relationships", |
| | "topic_security_requirements", |
| | "neg_request", |
| | "ticket_accepted", |
| | "relationship", |
| "requirements", | "requirements", |
| "BPMN" | "bpmn", |
| | "ticket", |
| | "blockly", |
| | "generated_python" |
| ] | ] |
| }, | }, |
| "gate": "2eec17eb6408566fbff8097042749a2e9c345fe1ba40a8aaee3354a18988fa27" | "gate": "2eec17eb6408566fbff8097042749a2e9c345fe1ba40a8aaee3354a18988fa27" |
| } | } |
| | }, |
| | "classification": { |
| | "schema": "sharix.knowledge.classification.v1", |
| | "products": [ |
| | "sharix_open" |
| | ], |
| | "audiences": [ |
| | "developer", |
| | "support", |
| | "reviewer", |
| | "ai" |
| | ], |
| | "material": "scenario", |
| | "topics": [ |
| | "handlers/relationships", |
| | "security/requirements" |
| | ], |
| | "tag_terms": [ |
| | "audience_developer", |
| | "audience_support", |
| | "audience_reviewer", |
| | "audience_ai", |
| | "product_sharix_open", |
| | "material_scenario", |
| | "topic_handlers_relationships", |
| | "topic_security_requirements", |
| | "neg_request", |
| | "ticket_accepted", |
| | "relationship", |
| | "requirements", |
| | "bpmn", |
| | "ticket", |
| | "blockly", |
| | "generated_python" |
| | ], |
| | "registry_document": "ShariXKnowledgeClassification", |
| | "state_meaning": "lifecycle относится к описываемому коду, а status к редакции документа; implemented не означает успешный runtime тест" |
| | }, |
| | "classification_review": { |
| | "date": "2026-10-31", |
| | "source": "Содержание текущей страницы и проверенный словарь классификации", |
| | "body_scope": "rewrite" |
| | }, |
| | "source_review_20261031": { |
| | "kind": "source_analysis_not_runtime_acceptance", |
| | "evidence_field": "extensions.source_evidence", |
| | "checked_on": "2026-10-31", |
| | "all_original_evidence_hashes_match_fresh_git": true, |
| | "canonical_generation": "Both runnable and generated copies match; no handler executed." |
| } | } |
| }, | }, |
| "content_sha256": "a398a139461c8779d75163af1c7e0d3113fe0db5970f1de4bd0d510600c85691", | "content_sha256": "eef48c5b15663a00e305d472ebe4abbc4da6aed8fbba2d92bced83a66ac8b64f", |
| "schema": 1 | "schema": 1 |
| } | } |
| ~~NOCACHE~~ | ~~NOCACHE~~ |
| |
| **Область:** ShariX Open. **Обработчик:** ''open_neg_request_accepted'', тип ''NEG_REQUEST'' (4), рабочий статус ''ACCEPTED'' (421). Опубликованный Python на 28.10.2026 побайтово совпадает с каноническим renderer его 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#trebovanija|Доступ → Требования]]. |
| | |
| | |
| | |
| | **Область:** 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'' здесь не проверяется. | Handler сопровождает уже одобренный запрос на публичную ''dbsynce.Relationship'': проверяет обязательные требования, запрашивает активацию и затем ждёт контрольного срока закрытия Ticket. Он не создаёт отсутствующую связь и не считает ACCEPTED доказательством выполненных requirements. ''NEGREQ_AUTOACCEPT'' здесь не проверяется. |
| |
| Relationship этого сценария — направленная запись с ''user_who'', ''user_whom'', ''neg_type'', необязательной company и ссылкой ''ticket_status''. Это не Permissions, не универсальная выдача LDAP-роли и не отдельная модель Relationship/клиента ShariX Platform. В этой ветви нет permission-specific синхронизации Client/CorpClient из ACCESS_REQUEST. | 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 успешно пройдены. | Ключевое отличие от ACCESS_REQUEST/ACCEPTED: **Relationship активируется до ожидания срока закрытия**. Контрольный срок относится к Ticket и не задерживает саму активацию, если requirements и backend gate успешно пройдены. |
| При первоначальном ''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 операции. | При первоначальном ''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 операции. |
| |
| Активация, уведомления и CLOSED — раздельные операции. Уже active Relationship не откатывается из-за ошибки последующего закрытия Ticket. Если существующая active Relationship позднее имеет невыполненные requirements, текущий handler сам её не деактивирует: он остаётся в ветви ожидания; текст уведомления не заменяет чтение сохранённого статуса. | У этого процесса три самостоятельных результата: |
| | |
| | * активация Relationship; |
| | * доставка уведомлений; |
| | * перевод Ticket в CLOSED. |
| | |
| | Ошибка последующего закрытия Ticket не откатывает уже active Relationship. Если требования позднее не выполнены, текущий handler сам не деактивирует связь: он остаётся в ветви ожидания. Состояние нужно читать в сохранённой Relationship, а не выводить из текста уведомления. |
| |
| ===== Контрольный срок и внешний цикл требований (BPMN) ===== | ===== Контрольный срок и внешний цикл требований (BPMN) ===== |
| </sharix-bpmn> | </sharix-bpmn> |
| |
| Для закрытия используется **''NEG_REQUEST_DECLINED_CLEANUP_GRACE_DAYS'' даже в ACCEPTED**. Это точное имя текущей реализации, несмотря на слово DECLINED. Возраст сравнивается с ''Ticket.updated_at''; минимум настройки — 0 дней. Deadline — ''updated_at + grace_days'', следующий defer — минимум deadline и ''now + DEFERRED_TICKET_RECHECK_SECONDS''. Локальная причина и строка журнала — ''neg_request_close_grace''. | Для контрольного срока используются: |
| | |
| | * **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 новой заявкой на взаимоотношение. | До истечения grace Relationship уже может быть active, а Ticket оставаться ACCEPTED. При каждом повторном проходе Python снова выполняет поиск, проверку requirements и запрос активации прежде, чем дойти до проверки срока. Здесь нет marker «активировать только один раз», аналогичного completed у профильных ST_REQUEST. Нельзя считать повторный Event новой заявкой на взаимоотношение. |
| Defer хранится в памяти и освобождает worker. При рестарте runtime заново получает актуальный снимок. Ошибку scoped списка нельзя считать подтверждённой пустой очередью. | Defer хранится в памяти и освобождает worker. При рестарте runtime заново получает актуальный снимок. Ошибку scoped списка нельзя считать подтверждённой пустой очередью. |
| |
| При диагностике различайте одобрение Ticket, фактическую Relationship и её направление/тип, результат requirements, ответ активации, актуальный updated_at и отдельное CLOSED. Active при ACCEPTED до контрольного срока может быть штатным состоянием. В текущем lifecycle из ACCEPTED доступны DECLINED или CLOSED при соответствующих правах; одно изменение статуса Ticket не заменяет доменное действие над Relationship. | При диагностике записать отдельно: |
| | |
| | * одобрение и текущий статус Ticket; |
| | * фактическую Relationship, её направление и тип; |
| | * результат requirements; |
| | * ответ операции активации; |
| | * актуальный updated_at и рассчитанный срок; |
| | * результат отдельного перехода CLOSED. |
| | |
| | Active при ACCEPTED до контрольного срока может быть штатным. Допустимые переходы ACCEPTED → DECLINED/CLOSED не подменяют доменное действие над Relationship. |
| |
| ===== Проверенные источники ===== | ===== Проверенные источники ===== |
