Модели состояний

Что такое модель состояний

Модель состояний — это специальный тип поля (State Model, см. Типы полей) который описывает жизненный цикл записи: набор возможных статусов и допустимые переходы между ними. В отличие от обычного поля со списком значений, статус нельзя сменить на произвольный — доступны только те статусы, в которые разрешён переход из текущего.

В одной сущности может быть только одно поле типа State Model.

Готовый, разобранный по шагам пример того, как модель состояний работает на практике — статусы заявки, кто их меняет, что происходит при каждом переходе — смотрите в Service Desk (IT-поддержка): там вся механика показана на конкретной цепочке статусов «Новая → Назначена → В работе → … → Закрыта».

Статусы

Каждый статус модели состояний задаётся тремя атрибутами:

• название — мультиязычная подпись, которая видна пользователям;
• значение — техническое значение, которое реально сохраняется в данных записи;
• цвет — для визуального выделения статуса в списках, карточке и таймлайне.

У статуса нет отдельных флагов «начальный» или «финальный» — это вычисляется через переходы:

• начальным считается статус, в который ведёт переход без указанного источника (то есть назначается записи при её создании);
• финальным (терминальным) считается статус, из которого не настроено ни одного исходящего перехода — в карточке записи и на таймлайне такой статус помечается значком «финальный».

Переходы

Переход — направленная связка «из статуса А в статус Б». Настраиваются они в редакторе сущности, на конфигурации поля State Model: для каждого статуса администратор указывает, в какие другие статусы из него можно перейти.

Переход не привязан к конкретной роли или пользователю — кто угодно с правом редактировать запись (и видеть это поле) может выполнить любой из разрешённых переходов. Ограничение конкретных людей или ролей, которые должны переводить запись между статусами, реализуется не самой моделью состояний, а соответствующей бизнес-логикой — например, назначением задачи нужной роли в бизнес-процессе, который и переводит статус по итогам выполнения задачи.

Как это выглядит в карточке записи

Поле статуса в карточке записи — это выпадающий список, но в нём показаны не все существующие статусы, а только те, переход в которые разрешён из текущего статуса записи. Например, если из статуса «В работе» настроены переходы только в «Ожидание» и «Решена», то именно эти два варианта (и больше ничего) увидит пользователь в выпадающем списке.

Если для статуса не настроено ни одного исходящего перехода (он терминальный, но это, возможно, ошибка конфигурации, а не намеренное финальное состояние), список статусов на всякий случай показывает все доступные варианты, а под полем появляется предупреждение, что переходов из текущего статуса не настроено — это защита от того, чтобы запись не «зависала» в статусе, откуда нет выхода.

Таймлайн статусов

Если у сущности настроено поле State Model, на карточке записи появляется вкладка статуса с визуальным таймлайном: граф, где узлы — это статусы, а стрелки — настроенные переходы. На графе:

• текущий статус записи выделен;
• уже пройденные статусы отмечены как посещённые;
• статусы, в которые запись ещё не попадала, показаны бледно и пунктиром;
• терминальные статусы помечены отдельным значком.

Клик по любому пройденному или текущему статусу открывает историю изменений записи за то время, когда она находилась в этом статусе. Таймлайн — это инструмент просмотра истории конкретной записи, а не место настройки переходов (настройка переходов — отдельный экран в редакторе сущности).

Один набор статусов — несколько подтипов записей

Если в сущности есть подтипы записей (поле типа Type Extender, см. Типы полей), статусы не дублируются для каждого подтипа. Все статусы (названия, цвета, значения) хранятся один раз в общем реестре сущности. Для каждого подтипа администратор отдельно настраивает только:

• какие из общих статусов доступны этому подтипу (отметкой галочками);
• какие переходы между этими статусами действуют именно для этого подтипа.

На практике это означает: если нужно переименовать статус или поменять его цвет, это делается один раз и сразу применяется ко всем подтипам, где этот статус используется. А чтобы у разных подтипов были разные жизненные циклы (например, у «Инцидента» — один набор переходов, у «Запроса на изменение» — другой), достаточно настроить только переходы для каждого подтипа, не пересоздавая сами статусы.