Каталог разрешений

Доступ в X7 Insight собран из атомарных разрешений вида «объект.действие» (например, data.update). Роли — это просто именованные наборы таких разрешений, выданные принципалу в определённой области. Ниже — каталог того, что вообще можно разрешить, сгруппированный по рабочим областям, и принципы, по которым система принимает решение.

Разрешение = видимость

Вы видите на экране только те кнопки и разделы, на которые у вас есть право в текущем контексте. Если действия нет — значит, оно вам недоступно здесь. Это UX-подсказка; настоящую защиту обеспечивает сервер, проверяя право на каждое действие.

Дизайн и сборка исследования

Право	Что разрешает
study.create / study.read / study.configure	создавать, видеть и настраивать исследование
study.lifecycle.change	переводить исследование по статусам (черновик → UAT → активно → …)
studyversion.create / studyversion.update	создавать и править версию дизайна (правки — только в черновике)
studyversion.submit_review / .approve / .publish / .retire	вести версию по циклу: на ревью, утвердить, опубликовать, отозвать; вернуть версию из ревью в черновик (тем же submit_review или approve)
mdr.read	читать метаданные исследования (формы, справочники, правила)
designcomment.read / designcomment.write	видеть и оставлять/решать замечания ревью дизайна (ADR‑054; чтение идёт вместе с mdr.read)
translation.manage / translation.approve	вести и утверждать переводы
site.activate / site.deactivate	активировать центр на опубликованной версии; закрывать и открывать
designtemplate.read / designtemplate.manage	видеть и вести библиотеку шаблонов дизайна арендатора

Утверждение: разделение обязанностей (ADR‑074)

Утверждение версии дизайна (и бандла перевода) проходит через разделение обязанностей. По умолчанию режим мягкий: автор может утвердить собственный объект, но такой акт всегда метится в аудите как self_approved. Строгий режим (настройка core.sod.strict_approvals на арендатора или исследование) требует, чтобы утверждающий не был автором. Единственное исключение — персональный ваивер studyversion.self_approve / translation.self_approve (семейство *.self_approve): документированное послабление для организаций без второй пары рук (ADR‑042). Модулю такой ваивер недоступен.

Субъекты и данные

Право	Что разрешает
subject.create / subject.read	заводить и видеть субъектов
subject.status.change	менять статус субъекта (включение, выбытие и т. д.)
subject.status.correct	исправлять ошибочно проставленный статус вне автомата (с причиной)
subject.randomize	рандомизировать субъекта (запись номера и слепого кода)
subject.migrate_version	переводить субъектов на новую версию дизайна
visit.create / visit.update	создавать визиты (в т. ч. внеплановые), ставить дату/пропуск
form.instance.create / form.instance.read / form.mark_complete	заводить, видеть формы и отмечать их заполненными
data.read	читать значения
data.enter	первичный ввод значения (причина не нужна)
data.update	правка сохранённого значения (обязательна причина, RfC)
data.mark_not_done	отмечать «не выполнено» / «недоступно»
data.unblinded.read	видеть расслеплённые слепые значения (чтение аудируется)
form.entry.<метка>	вводить данные в формы с ограничением ввода (см. ниже)

Ограничение ввода формы (form.entry.*)

Дизайнер может пометить форму меткой ограничения ввода — например, lab у «Лабораторных результатов». Тогда запись в такую форму требует, помимо обычных data.enter/data.update, ещё и права form.entry.lab — его кладут в роль выделенного вводчика (например, «Вводчик от лаборатории»). Остальные видят форму по своим правам, но не могут её заполнять. Право появляется в каталоге автоматически при установке метки в дизайне. См. Управление доступом.

Почему ввод и правка — разные права

data.enter и data.update намеренно разделены. Например, участник ePRO может вводить свои ответы, но не править сохранённые — исправления делает только персонал и всегда с причиной. См. Ввод данных и ослепление.

Мониторинг и очистка

Право	Что разрешает
query.read / query.open / query.answer	видеть, открывать и отвечать на запросы
query.close / query.reopen / query.cancel	закрывать, переоткрывать и отменять запросы
query.assign	назначать запросы исполнителям (метка очереди)
data.sdv.verify / data.sdv.unverify	ставить и снимать отметку верификации по источнику (SDV)
data.review.medical	проводить медицинский обзор данных
data.coding.write	ставить статус медицинского кодирования

Подписи, блокировки, экспорт

Право	Что разрешает
signature.apply / signature.read	применять электронную подпись и видеть подписи
lock.read	видеть блокировки и их историю
lock.apply.soft / lock.apply.hard	накладывать мягкую и жёсткую блокировку
lock.release.soft / lock.release.hard	снимать мягкую блокировку / переоткрывать базу
export.run / export.read	запускать выгрузки и видеть их историю

Администрирование и доступ

Право	Что разрешает
access.grant	выдавать и отзывать гранты, назначать роли
access.delegate	делегировать собственные права (глубина 1, в пределах своих прав и срока)
access.read	просматривать выданные гранты и роли (админ и инспектор)
role.manage	создавать и править кастомные роли
principal.manage	заводить и деактивировать учётные записи арендатора
audit.read	читать аудиторский след
audit.verify	запускать проверку хеш-цепочки
settings.read / settings.write	читать и менять настройки платформы в области
platform.administer	исключительные инсталляционные операции

Модули

Право	Что разрешает
module.register	регистрировать манифест модуля (на уровне платформы)
module.enable / module.disable	включать и выключать модуль в области
module.configure	настраивать модуль
mod.<модуль>.<объект>.<действие>	собственные права модуля из его манифеста

Что модуль не может никогда

Модулям запрещено запрашивать права администрирования доступа (access.*, role.manage, module.*, platform.administer), снимать блокировки (lock.release), подписывать за человека (signature.apply) и запускать верификацию аудита (audit.verify). Модуль не администрирует доступ и не подписывает вместо человека. См. Модули.

Принципы доступа

Как именно система решает, можно ли действие. Понимание этих четырёх принципов объясняет почти любое «почему мне нельзя»:

• Default deny (по умолчанию — запрет). Нет подходящего гранта — доступа нет. Ничего не разрешено «по умолчанию».
• Deny-wins (запрет побеждает). Если на пути ресурса есть хоть один запрещающий грант (deny), доступа нет — даже при наличии разрешающих. Явный запрет сильнее любого разрешения.
• Scope (область действия). Право выдаётся на путь исследование → центр → субъект → форма → поле и действует на этот путь и всё, что ниже. Право на центр не даёт прав на всё исследование; иерархия — и есть механизм массовости, «звёздочек» (wildcards) нет.
• Time-boxed (срок действия). У гранта может быть окно «с… по…». Вне окна он не действует. Отзыв и истечение срока действуют немедленно; например, доступ инспектора выдают с датой окончания инспекции.

Разделение обязанностей (SoD)

Отдельные правила запрещают (block) или предупреждают (warn) при опасном совмещении прав у одного лица. Дефолтные: «кто ввёл данные, тот не верифицирует их по источнику» (block); «подписант и верификатор SDV» (warn); «выдающий доступ и правящий данные» (warn). Проверка выполняется в момент выдачи гранта или назначения роли. Совмещение по политике warn возможно, но факт фиксируется в аудите.

«Почему мне нельзя?»

Модель объяснима: система умеет показать перечень применимых грантов для любого решения — это основа экрана «почему». Если действие недоступно, обратитесь к администратору доступа арендатора. См. Роли и доступ.

Роли и доступКак из прав собираются роли и откуда берётся ваш доступ.

ГлоссарийПраво, грант, scope, роль, SoD, принципал — простыми словами.

Жизненные циклы и оси статусовКакие права нужны для каждого перехода.

Ослепление и приватностьКак data.unblinded.read управляет видимостью слепых значений.