Назначение: Контракт. Продукт: ShariX Open · Общий компонент.

Для кого: Разработчик · Администратор · Интегратор · Поддержка · Рецензент и приёмщик · Нейросеть.

Темы: Доступ → Требования · Доступ → Полномочия · Документы → Жизненный цикл.

В ShariX Open нужно различать:

• Requirement/policy — что требуется от субъекта в данном контексте.
• Evidence — какой документ, проверка или связь подтверждает выполнение.
• Permissions/Relationship и другие активируемые объекты — результат канонической активации, а не сама политика.
• Effective access — допустимо ли пользоваться уже выданным объектом сейчас.

Созданная заявка, LDAP/Django-группа и PASSED отдельной проверки не подменяют всю цепочку.

• Для Permissions политика задаётся в PermissionRequirementPolicy по id_permissions и области метасервиса; конкретная Permissions — выдача/заявка, а не независимый редактор общей политики.
• Для других поддерживаемых объектов сохраняются их требования и нормализованные RequirementRule.
• Обязательные правила ServiceCategory наследуются Service; тариф не может ослабить такое правило собственной строкой.
• evaluate_requirements объединяет historical compact baseline и normalized rules. Добавление новой Rule не отключает старый обязательный baseline.

В compact-строке D — документы, C — проверки, B — необходимые связи. Старые уровни S/M/P/U сохраняют грамматику: C уже является маркером секции, поэтому Company-level требования задаются normalized Rule, а не неоднозначной буквой в старой строке. Нормализованные kinds — DOCUMENT, CHECK, RELATIONSHIP; contextual predicates проверяются соответствующим механизмом.

1. Определяется владелец политики и пользователь, к которому относится требование.
2. Собираются применимые compact/normalized/contextual правила.
3. Каждое правило получает evidence/state/reason; общий ok требует удовлетворения всех обязательных результатов.
4. Отсутствующий обязательный subject даёт отказ, а не выбор reviewer как подставного пользователя.
5. Optional-пункт может отсутствовать по своему контракту; это не разрешение игнорировать обязательный пункт рядом.

Для документа проверяются содержимое, revision/schema/identity, expiry и уровень. Для RequirementCheck — определение, область, subject, текущий результат и срок действия. При завершении check каноническая операция блокирует PENDING attempt и проверяет связь конкретного Ticket; результат другой попытки не переносится произвольно.

Initial activation строгая: требования должны выполняться перед active. После выдачи assess_effective_access различает:

• INACTIVE — объект не active; пользоваться нельзя.
• EXPIRED — истёк собственный expire_date объекта; это жёсткая граница.
• ACTIVE_VALID — требования актуальны, доступ разрешён.
• ACTIVE_RECHECK_REQUIRED — evidence изменилось/устарело; по умолчанию доступ сохраняется с требованием повторной проверки.
• BLOCKED — policy requirements_drift_access=block требует немедленного запрета при drift.

Следовательно, истечение evidence не всегда автоматически отзывает уже выданное право; и наоборот, active в БД не гарантирует effective access при expiry/block policy. Политику выбирают осмысленно по предметным условиям.

Штатные actions/reconciliation готовят недостающие документы и проверки; manage.py reconcile_requirements относится к каноническому механизму переоценки. Перед запуском на данных установки уточняются его область и параметры. Handler сопровождает процесс, а domain backend хранит результат.

1. При отказе смотрите конкретное evidence state/reason, subject и scope.
2. Разделяйте needs_upload, needs_verification, failed/expired и отсутствующую связь.
3. Сверяйте current policy и собственный expire_date выданного объекта.
4. Не обходите gate ручным active и не восстанавливайте роль одной группой, если каноническое Permissions запрещает доступ.

Связанный жизненный цикл документов описывает версию доказательства; ACCESS_REQUEST ACCEPTED — применение решения в процессе.

Проверено по Git-исходникам 31.10.2026. Состояние исходников отделено от состояния конкретной установки; команды ниже при редакционной проверке не выполнялись, бизнес-данные и значения секретов не читались.

• sharix-open-backend / models/requirements.py.
• sharix-open-backend / lib/requirements_codec.py.
• sharix-open-backend / lib/requirement_checks.py.
• sharix-open-backend / lib/contextual_requirements.py.
• sharix-open-backend / lib/activation.py.
• sharix-open-backend / lib/effective_access.py.
• sharix-open-backend / lib/requirement_actions.py.

Нормативное уточнение от 31.10.2026, а не сообщение о развёрнутом исправлении. Employee обозначает внутреннюю связь человека с юридическим лицом. Представитель компании, исполнитель, администратор и другие связанные с ней люди могут иметь такую запись. Эта связь остаётся в ведении юридического лица; Сервис или Платформа не должны превращать её наличие в самостоятельный внешний допуск.

LDAP-роль открывает соответствующий интерфейс для подготовки данных, загрузки документов и заполнения полей. Она добавляется при подаче заявки, до окончательного решения. Разрешение на конкретную операцию проверяется отдельно: нужны действующее разрешение нужного вида, соответствующая компания или область действия, установленное внешнее отношение и остальные требования операции. Роль по отношению к одному Сервису не предоставляет права на любую компанию.

Contract обозначает внешнее договорное отношение компании с Сервисом и не заменяет внутренний employee. Участник, не являющийся представителем компании по договору, получает свою область через собственное разрешение; отношение «сам с собой» для этого не требуется. ACCESS_REQUEST и NEG_REQUEST имеют разные предметы и могут идти в разные списки, даже если решения принимает один человек.

Запрос роли Сервиса не должен автоматически создавать внешний NEG_REQUEST(employee). Исторические записи сохраняются: это уточнение не разрешает удалять, автоматически активировать или массово восстанавливать отношения. Подготовленная правка API и проверок должна пройти отдельное применение и runtime-приёмку; эта страница сама по себе не подтверждает состояние серверов.