Назначение: Контракт. Продукт: 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.