Перейти к основному содержимому

Концепции — жизненные циклы и доступ

Эта страница отвечает на два вопроса, которые в проде возникают чаще всего:

  1. Почему в один момент действие доступно, а в другой нет.
  2. Какие статусы реально управляют процессом.

1) Модель доступа​

Доступ всегда вычисляется как пересечение трёх факторов:

  • права роли;
  • контекст (global/study/site);
  • статус объекта процесса.

2) Важная оговорка про “статусы”: их несколько и они независимы​

В UI вы увидите разные статусы, и они отвечают за разные вещи:

  • Core status (Status.*) — базовый статус записи (Study/Site/CRFVersion/и т.д.). Он часто определяет “можно ли вообще менять объект”.
  • Event status — статус визита (Study Event): управляет read‑only контуром визита.
  • Event CRF status — статус формы в визите: управляет стадиями ввода IDE/DDE/Admin Edit/Lock.
  • Resolution status — статус Query (Discrepancy Note): это отдельный контур качества данных.

Из-за этого возможно:

  • визит COMPLETED, но конкретная форма ещё не DOUBLE_DATA_ENTRY_COMPLETE (например, DDE в процессе);
  • форма LOCKED, но визит ещё не LOCKED (локи могут быть на разных уровнях);
  • query OPEN, даже если форма завершена (это нормально: query закрывается отдельным процессом).

2) Статусы исследования (core status)​

Для Study/Site и части сущностей используются базовые статусы:

  • PENDING, AVAILABLE — рабочие;
  • UNAVAILABLE, FROZEN, LOCKED, SIGNED, DELETED — ограничивающие;
  • в read-only статусах изменения блокируются процессно, даже при наличии прав.

Практика:

  • если исследование не в PENDING/AVAILABLE, то дизайн/настройки часто становятся read‑only;
  • многие “кнопки пропали” на самом деле потому, что study/site стал FROZEN/LOCKED/SIGNED.

3) Жизненный цикл визита (Study Event)​

Основные статусы:

  • NOT_SCHEDULED, SCHEDULED, DATA_ENTRY_STARTED, COMPLETED, STOPPED, SKIPPED, SIGNED, LOCKED.

Критично для операций:

  • LOCKED, SIGNED, STOPPED, SKIPPED переводят CRF визита в read-only.

4) Жизненный цикл формы (Event CRF)​

Основные статусы:

  • UNCOMPLETED;
  • INITIAL_DATA_ENTRY → INITIAL_DATA_ENTRY_COMPLETE;
  • DOUBLE_DATA_ENTRY → DOUBLE_DATA_ENTRY_COMPLETE;
  • ADMINISTRATIVE_EDITING;
  • LOCKED.

Критично для операций:

  • LOCKED всегда read-only;
  • завершённая форма может снова перейти в процесс через ADMINISTRATIVE_EDITING (если роль и процесс разрешают).

5) Query resolution statuses​

Для Queries используется отдельный lifecycle:

  • OPEN, UPDATED, RESOLUTION_PROPOSED,
  • CLOSED, CLOSED_MODIFIED, NOT_APPLICABLE.

Это не «статус формы», а параллельный контур качества данных.

6) Таблица “что нужно для кнопки” (самое полезное)​

ДействиеМинимальные условияЧто чаще всего блокирует
Start/Continue Data Entryесть право на ввод данных в scope, визит не read‑onlyвизит SIGNED/LOCKED/STOPPED/SKIPPED, форма LOCKED, editing lock
Сохранитьнет блокирующих validation errorsошибки правил/валидаций, параллельная правка, устаревшая версия данных (409)
Complete (завершить ввод)форма в IDE/DDE контуре, все обязательные поля/валидации пройденыобязательные поля, DDE не завершён, pre‑checks
SDV set/unsetформа *_COMPLETE, визит не SIGNED/LOCKED, право data.perform_sdv, SDV требуетсявизит подписан/заблокирован, форма LOCKED, нет права
Sign CRFформа DOUBLE_DATA_ENTRY_COMPLETE, нет blocking queries, парольDDE не завершён, есть blocking query
Sign Eventвизит COMPLETED, обязательные формы готовы, нет blocking queries, парольнезавершённые required CRF, blocking queries
Lock Eventвсе открытые формы визита завершены, нет HIGH/CRITICAL queries OPEN/UPDATED, право lockесть незавершённые формы, критичные queries
Administrative Editing (RFC)право data.administrative_editing, процесс разрешаетотсутствие права, SOP ограничения, read‑only статусы

Подробно: Data Entry и Closeout.

6) Почему «исчезла кнопка»​

Порядок проверки:

  1. Правильный ли контекст страницы.
  2. Есть ли право в этом контексте.
  3. Не блокирует ли статус визита/CRF/исследования.
  4. Не блокируют ли процессные условия (owner-gating, DDE, pre-checks).

Смежные страницы​