Применение правил к состояниям рабочего процесса (процесс наследования)

Azure DevOps Services | Azure DevOps Server 2022 г. - Azure DevOps Server 2019 г.

После добавления или изменения состояний рабочего процесса для типа рабочего элемента может потребоваться определить одно или несколько правил, применяемых в зависимости от изменения состояния рабочего процесса. Добавление правил в состояния рабочего процесса поддерживает следующие сценарии:

• Поддержка процесса утверждения
• Предотвращение установки недопустимого состояния неавторизованными пользователями
• Сделайте поле обязательным, только для чтения или другое значение на основе изменений состояния
• Ограничение перехода из одного состояния в другое
• Ограничение или разрешение переходов состояния для определенных пользователей или групп
• Ведение управляемого рабочего процесса для поддержки требований аудита
• Автоматизация закрытия родительских рабочих элементов

Ознакомьтесь с этой статьей, чтобы понять, как определить правила, которые применяются при изменении состояния рабочего процесса.

• Общие сведения о типах правил рабочего процесса
• Ограничения состояния рабочего процесса и правил, а также рекомендации
• Задайте значение поля или сделайте поле обязательным или только для чтения на основе выбора состояния
• Ограничение переходов между состояниями
• Ограничение или разрешение переходов состояния для определенных пользователей или групп
• Автоматизация переходов состояния родительских рабочих элементов

Важно!

Эта статья относится к Azure DevOps Services и Azure DevOps Server 2019 и более поздних версий. Сведения о настройке любого проекта, определенного в коллекции для TFS 2018 или более ранней версии, см. в статье Локальная модель xml-процессов.

Правила рабочего процесса

В следующей таблице указаны три группы правил рабочего процесса, которые можно определить. Первая группа применяет стандартные действия, когда рабочий элемент создается, находится в выбранном состоянии или перемещается из одного состояния в другое. Эти стандартные действия задают значение поля или делают поле обязательным или обязательным. В этой группе можно указать одно или два условия и несколько действий.

Вторая и третья группы поддерживают ограничение переходов состояния. Эти две группы позволяют указать одно и только одно условие, указывающее состояние, в которое перемещен рабочий элемент. Затем можно указать одно или несколько действий, чтобы ограничить переход из этого состояния в другие.

---

Condition

Поддерживаемые действия

---

Задайте значение поля или сделайте значение только для чтения или обязательным на основе состояния

---

В зависимости от членства пользователя или группы задайте атрибут поля или ограничьте переход состояния.

---

Примечание

При настройке наследуемого процесса все проекты, использующие этот процесс, автоматически обновляются с учетом настроек. По этой причине рекомендуется создать тестовый процесс и тестовый проект, если у вас есть ряд настроек для тестирования настроек перед их развертыванием в организации. Дополнительные сведения см. в статье Создание унаследованных процессов и управление ими.

Ограничения состояния рабочего процесса и правил

В следующей таблице описаны состояние рабочего процесса и ограничения правил для процесса наследования.

Объект	Ограничение на наследование
Типы рабочих элементов, определенные для процесса	64
Состояния рабочего процесса, определенные для типа рабочего элемента	32
Правила, определенные для типа рабочего элемента	1024

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

• Сведите к минимуму количество правил, определяемых для WIT. Хотя для типа рабочего элемента можно создать несколько правил, это может негативно повлиять на производительность при добавлении и изменении рабочих элементов пользователем. Когда пользователи сохраняют рабочие элементы, система проверяет все правила, связанные с полями для типа рабочего элемента. При определенных условиях выражение проверки правила будет слишком сложным для вычисления SQL.
• Сведите к минимуму количество определяемых пользовательских типов рабочего элемента.

Правила рабочего процесса применяются при добавлении или изменении рабочих элементов через любой из следующих интерфейсов:

• Веб-портал: форма рабочего элемента, массовые обновления, обновления в представлении запроса
• Веб-портал: канбан-доска или доска задач, перемещение рабочего элемента в столбец
• Visual Studio 2017 и более ранних версий, форма рабочего элемента
• Формат CSV-файла: массовый импорт или обновление
• Excel: массовый импорт или обновление
• REST API: добавление или изменение рабочих элементов

Определение правила

Перед определением правила на основе состояний рабочего процесса убедитесь, что вы сначала определили следующие элементы:

• Состояние рабочего процесса, которое требуется, как описано в разделе Настройка рабочего процесса
• Если правило требует спецификации настраиваемого поля, добавьте это поле в тип рабочего элемента, как описано в разделе Добавление полей и управление ими.
• Если правило требует спецификации группы безопасности для предоставления или ограничения изменений на основе членства пользователей или групп, определите эту группу безопасности, как описано в разделе Добавление или удаление пользователей или групп, управление группами безопасности.

Основные сведения об определении правил см. в разделе Добавление настраиваемого правила. Необходимо выполнить предварительные требования, определенные в этой статье.

Задайте значение поля или сделайте поле обязательным или обязательным для чтения

С помощью первой группы правил можно указать одно или два условия и до 10 действий для каждого правила.

Пример утверждения руководителя команды перед активной работой

В этом примере команды разработчиков хотят убедиться, что пользовательская история не будет работать до тех пор, пока не будет одобрена руководителем команды. Используются состояния рабочего процесса по умолчанию, и добавляются только одно настраиваемое поле "Утверждено" и группа безопасности "Группа потенциальных групп".

Состояния рабочего процесса по умолчанию

Требования к правилам

Чтобы обеспечить утверждение перед активной работой, необходимо определить следующие правила:

• Требовать, чтобы поле Утверждено было заполнено при перемещении состояния с "Новое " на "Активно"
• Запретить пользователям, которые не входят в группу потенциальных участников команды, заполнять поле Утверждено
• Очистите поле Утверждено при переходе в положение "Новое" или "Удалено"

Определения правил

Требования к правилам преобразуется в следующие четыре определения правил.

   

---

Имя правила

Condition

Действия

---

Утверждено снимите флажок При создании

Когда A work item state changes to New

Затем Clear the value of Approved By

Утверждено снимите флажок при удалении

Когда A work item state changes to Removed

Затем Clear the value of Approved By

Утверждено только для чтения

Когда Current user is not member of group Team Leads Group

Затем Make read-only Approved By

Утверждено обязательным

Когда A work item state changes from New to Active

Затем Make required Approved By

---

Ограничение переходов между состояниями

При указании условия A work item state moved from ...можно указать только это условие. Можно указать до 10 действий.

Пример ограничения переходов состояния и утвержденного состояния

В соответствии с терминологией, используемой бизнес-группой, для пользовательской истории определяются следующие состояния рабочего процесса. Наследуемые состояния New, Resolved и Removed скрыты. Вместо этого используются состояния "Предлагаемое", "Проверка" и "Вырезать ". Кроме того, определены три дополнительных состояния: Исследование, Проектирование и Утверждено. Эти состояния должны следовать последовательности, как показано на следующем рисунке.

Без каких-либо ограничений пользователи могут переходить из одного состояния в любое другое состояние, как вперед, так и назад в последовательности.

Требования к правилам

Чтобы поддерживать более контролируемый рабочий процесс, бизнес-группа решила ввести правила, которые будут поддерживать следующие переходы вперед и обратное состояние для типа рабочего элемента User Story.

• Предложение может только перейти к исследованию и вырезать
• Исследование может только перейти к проектированию и вырезать
• Проект можно переместить только в исследовательские, утвержденные и вырезанные
• Утвержденные можно переместить только в конструктор, активный и вырезанный
• Активный может переходить только к разделу "Проверка"
• В разделе Проверка можно перейти только к активному (обнаружена дополнительная работа), Закрыта или Вырезана
• Закрытый может перемещаться в области Исследования, Проектирование, Активный, В проверке (позволяет в случаях, когда пользователь закрыл рабочий элемент по ошибке)
• Вырезать можно только перейти к предложению.

Примечание

При ограничении переходов состояний учитывайте случаи, когда пользователь перемещает состояние по ошибке. Вы хотите, чтобы пользователи могли корректно восстанавливаться.

Кроме того, бизнес-группа хочет применить правила для обязательных полей:

• Требовать, чтобы поле Утверждено было заполнено при перемещении состояния с "Утверждено" на "Активно"
• Только пользователям, входящим в группу "Авторизованные утверждающие", заполнять поле "Утверждено"
• Снимите флажок "Утверждено" при перемещении состояния в положение "Вырезать"
• Требовать , чтобы условия принятия были заполнены при переходе состояния в активное

Определения правил

Чтобы реализовать указанные выше ограничения, администратор процесса добавляет настраиваемое поле удостоверений Утверждено , группу безопасности Авторизованные утверждающие и следующие одиннадцать правил.

   

---

Имя правила

Condition

Действия

---

Предлагаемое состояние

Когда A work item state moved from Proposed

Затем Restrict the state transition to Design
И Restrict the state transition to Approved
И Restrict the state transition to Active
И Restrict the state transition to In Review
И Restrict the state transition to Closed

Состояние исследования

Когда A work item state moved from Research

Затем Restrict the state transition to Proposed
И Restrict the state transition to Approved
И Restrict the state transition to Active
И Restrict the state transition to In Review
И Restrict the state transition to Closed

Состояние конструктора

Когда A work item state moved from Design

Затем Restrict the state transition to Proposed
И Restrict the state transition to Research
И Restrict the state transition to Active
И Restrict the state transition to In Review
И Restrict the state transition to Closed

Состояние "Утверждено"

Когда A work item state moved from Approved

Затем Restrict the state transition to Proposed
И Restrict the state transition to Research
И Restrict the state transition to Design
И Restrict the state transition to In Review
И Restrict the state transition to Closed

Активное состояние

Когда A work item state moved from Active

Затем Restrict the state transition to Proposed
И Restrict the state transition to Research
И Restrict the state transition to Design
И Restrict the state transition to Approved
И Restrict the state transition to Closed

В состоянии "Проверка"

Когда A work item state moved from In Review

Затем Restrict the state transition to Proposed
И Restrict the state transition to Research
И Restrict the state transition to Design
И Restrict the state transition to Approved

Закрытое состояние

Когда A work item state moved from Closed

Затем Restrict the state transition to Proposed
И Restrict the state transition to Cut

Состояние выреза

Когда A work item state moved from Cut

Затем Restrict the state transition to Research
И Restrict the state transition to Design
И Restrict the state transition to Approved
И Restrict the state transition to Active
И Restrict the state transition to In Review
И Restrict the state transition to Closed

Обязательные поля утвержденного состояния

Когда A work item changes from Approved to Active

Затем Make required Acceptance Criteria
И Make required Approved By

Авторизованные утверждающие

Когда Current user is not a member of Authorized Approvers

Затем Make read-only Approved By

Очистить поле "Утверждено"

Когда A work item state changes to Cut

Затем Clear the value of Approved By

---

Проверка ограничений перехода состояния

После определения правил для процесса и проекта, обновите браузер и проверка операции через форму рабочего элемента и из браузера Kanban.

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

Предложено	Исследования	Оформление	Approved
Активен	В обзоре	Закрыто	Вырезать

Ограничение перехода состояния на основе членства пользователя или группы

При указании одного из двух условий на основе членства Current user is member of group ... пользователя или группы или Current user is not member of group ...можно указать только одно условие. Кроме того, при указании действия Restrict the transition to state...можно указать только одно действие.

Примечание

К рабочим элементам применяются правила. Условные правила, основанные на членстве пользователя или группы, кэшируются для веб-браузера. Если вы не можете обновить рабочий элемент, возможно, вы столкнулись с одним из этих правил. Если вы считаете, что столкнулись с проблемой, которая не относится к вам, см. статью Проблемы с кэшированием базы данных IndexDB в форме рабочего элемента.

Автоматизация переходов состояния родительских рабочих элементов

Чтобы автоматизировать переходы состояния родительских рабочих элементов на основе назначений состояния, выполненных их дочерним рабочим элементам, можно добавить веб-перехватчик и использовать код и конфигурацию, предоставленные в проекте GitHub Automate State Transitions .

Примечание

Проект GitHub Automate State Transitions не поддерживается Azure Boards и, следовательно, не поддерживается командой разработчиков. Вопросы, предложения или проблемы, возникающие при использовании этих расширений, можно задать на странице проекта GitHub.

Автоматизация переназначения на основе изменения состояния

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

КогдаA work item state changes toРазрешено, затемCopy the value from созданов назначенное.

Похожие статьи

Примечание

Изменения, внесенные в унаследованный процесс, можно просмотреть в журнале аудита. Дополнительные сведения см. в статье Доступ к журналам аудита, экспорт и фильтрация.

• Настройка рабочего процесса
• Добавление настраиваемого правила
• Кэширование формы рабочего элемента