Различия

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

--- sharixopen:knowledge:scenarios:partner_request [2026/10/31 11:25] – [sharixknowledge] approved package sx_knowledge_api_open
+++ sharixopen:knowledge:scenarios:partner_request [2026/10/31 19:56] (текущий) – [sharixknowledge] approved package sx_knowledge_api_open
@@ Строка 174: / Строка 174: @@
         }
     },
-    "content_sha256": "b6d8a4ee0096fbad3b3640a370671fa26c259b2bc2b768e18f7dfbe58f8da21e",
+    "content_sha256": "36aec52bc51b5c805491e27ee84c412491bb749ae93317cbd252ea46061fe3d6",
     "schema": 1
 }
@@ Строка 243: / Строка 243: @@
   - Обеспечивает запрос полномочия PARTNER-ADMIN.
   - Обеспечивает дополнительные запросы полномочий для выбранных auto_roles.
-  - При METASERVICE-PROVIDER отдельно обеспечивает employee Relationship с собственным NEG_REQUEST.
+  - Исторический код при METASERVICE-PROVIDER отдельно создавал employee Relationship с NEG_REQUEST; по уточнению владельца ниже этот шаг не является внешним условием допуска и удаляется подготовленной правкой.
   - Обеспечивает contract Relationship с собственным NEG_REQUEST.
   - Вызывает предусмотренные действия по требованиям для созданных объектов.
@@ Строка 269: / Строка 269: @@
   * Каждое Permissions и его ACCESS_REQUEST.
   * Contract Relationship и соответствующий NEG_REQUEST.
-  * Employee Relationship, если выбрана роль исполнителя.
+  * Исторический Employee Relationship при выборе роли исполнителя; не считать самостоятельным внешним допуском.
   * Требования и результаты их проверки.
   * Членство пользователя в нужных группах и обновлённый контекст доступа.
@@ Строка 304: / Строка 304: @@
   * [[https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/778a3280cee115ba0efe3fdff7b0e708b0c10093/lib/partner_requests.py|sharix-open-backend: lib/partner_requests.py]].
   * [[https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/778a3280cee115ba0efe3fdff7b0e708b0c10093/lib/ticket_gen.py|sharix-open-backend: lib/ticket_gen.py]].
+===== Уточнение владельца: внутренняя связь employee и внешний допуск =====
+**Нормативное уточнение от 31.10.2026, а не сообщение о развёрнутом исправлении.** Employee обозначает внутреннюю связь человека с юридическим лицом. Представитель компании, исполнитель, администратор и другие связанные с ней люди могут иметь такую запись. Эта связь остаётся в ведении юридического лица; Сервис или Платформа не должны превращать её наличие в самостоятельный внешний допуск.
+LDAP-роль открывает соответствующий интерфейс для подготовки данных, загрузки документов и заполнения полей. Она добавляется при подаче заявки, до окончательного решения. Разрешение на конкретную операцию проверяется отдельно: нужны действующее разрешение нужного вида, соответствующая компания или область действия, установленное внешнее отношение и остальные требования операции. Роль по отношению к одному Сервису не предоставляет права на любую компанию.
+Contract обозначает внешнее договорное отношение компании с Сервисом и не заменяет внутренний employee. Участник, не являющийся представителем компании по договору, получает свою область через собственное разрешение; отношение «сам с собой» для этого не требуется. ACCESS_REQUEST и NEG_REQUEST имеют разные предметы и могут идти в разные списки, даже если решения принимает один человек.
+Запрос роли Сервиса не должен автоматически создавать внешний NEG_REQUEST(employee). Исторические записи сохраняются: это уточнение не разрешает удалять, автоматически активировать или массово восстанавливать отношения. Подготовленная правка API и проверок должна пройти отдельное применение и runtime-приёмку; эта страница сама по себе не подтверждает состояние серверов.
 ~~SHARIX_KNOWLEDGE_RELATED~~