Применение правил к состояниям рабочего процесса (процесс наследования)
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
После добавления или изменения состояний рабочего процесса для типа рабочего элемента определите правила, применяемые на основе изменения состояния рабочего процесса. Добавление правил в состояния рабочего процесса поддерживает следующие сценарии:
- Поддержка процесса утверждения
- Запретить несанкционированным пользователям устанавливать недопустимое состояние
- Сделайте поле обязательным или только для чтения или другим значением на основе изменений состояния
- Ограничение перехода от одного состояния к другому
- Ограничение или разрешение переходов состояния на определенных пользователей или групп
- Обслуживание управляемого процесса рабочего процесса, поддерживающее требования к аудиту
- Автоматизация закрытия родительских рабочих элементов
- Поддержка процесса утверждения
- Запретить несанкционированным пользователям устанавливать недопустимое состояние
- Сделайте поле обязательным или только для чтения или другим значением на основе изменений состояния
- Ограничение перехода от одного состояния к другому
- Автоматизация закрытия родительских рабочих элементов
- Поддержка процесса утверждения
- Сделайте поле обязательным или только для чтения или другим значением на основе изменений состояния
- Автоматизация закрытия родительских рабочих элементов
Внимание
Модель процесса наследования доступна для проектов, настроенных для поддержки. Если вы используете старую коллекцию, проверьте совместимость модели процесса. Если локальная коллекция настроена на использование локальной модели xml-процессов, можно использовать только эту модель процесса для настройки интерфейса отслеживания работы. Дополнительные сведения см. в разделе "Выбор модели процесса" для коллекции проектов.
Необходимые компоненты
Чтобы применить правила к состояниям рабочего процесса в Azure DevOps, вам потребуются определенные разрешения и уровни доступа:
Разрешения:
- Будьте администратором проекта для управления группами безопасности и разрешениями на уровне проекта, включающее правила настройки состояний рабочего процесса.
- Разрешение "Отслеживание рабочих элементов", позволяющее управлять областью отслеживания рабочих элементов, которую можно предоставить членам группы "Администраторы проектов" или с помощью определенных разрешений.
Уровни доступа:
- Имеют базовый доступ, который обычно достаточно для большинства пользователей, которым необходимо управлять рабочими элементами и применять правила к состояниям рабочего процесса.
Общие сведения о правилах рабочего процесса
В следующей таблице описаны три группы правил рабочего процесса, которые можно определить:
Стандартные действия:
- Применяется при создании рабочего элемента в выбранном состоянии или перемещении из одного состояния в другое.
- Действия включают задание значения поля, создание поля только для чтения или обязательное поле.
- Можно указать одно или два условия и несколько действий.
Ограничение переходов состояния (группа 1):
- Укажите одно условие, указывающее состояние рабочего элемента, перемещаемого из.
- Определите действия, ограничивающие переходы из этого состояния в другие состояния.
Ограничение переходов состояния (группа 2):
- Как и первая группа, укажите одно условие, указывающее состояние рабочего элемента, перемещаемого из.
- Определите действия, ограничивающие переходы из этого состояния в другие состояния.
В следующей таблице описаны две группы правил рабочего процесса, которые можно определить:
Стандартные действия:
- Применяется при создании рабочего элемента в выбранном состоянии или перемещении из одного состояния в другое.
- Действия включают задание значения поля, создание поля только для чтения или обязательное поле.
- Можно указать одно или два условия и несколько действий.
Ограничение переходов состояния:
- Укажите одно условие, указывающее состояние рабочего элемента, перемещаемого из.
- Определите одно или несколько действий, чтобы ограничить переходы из этого состояния в другие состояния.
Примечание.
Для некоторых функций требуется установка обновления Azure DevOps Server 2020.1. Дополнительные сведения см. в заметках о выпуске Azure DevOps Server 2020 с обновлением 1 RC1, досках.
Условия рабочего процесса и действия, которые можно задать, показаны на следующих изображениях. Стандартные действия можно применять при создании рабочего элемента в выбранном состоянии или перемещении из одного состояния в другое. Эти стандартные действия задают значение поля или делают поле доступным только для чтения или обязательным. Для этого набора правил можно указать одно или два условия и несколько действий.
Условие
Поддерживаемые действия
Установка значения поля или создание только для чтения или обязательного использования в зависимости от состояния
Ограничение перехода на основе состояния
Скрытие поля или создание поля только для чтения или обязательного на основе состояния и членства пользователей или групп
На основе членства пользователей или групп задайте атрибут поля или ограничьте переход состояния
Примечание.
При настройке унаследованного процесса все проекты, использующие этот процесс, автоматически отражают настройки. Чтобы обеспечить плавный переход, рекомендуется создать тестовый процесс и проект, который позволяет протестировать настройки перед их реализацией на уровне организации. Дополнительные сведения см. в разделе "Создание унаследованных процессов и управление ими".
Общие сведения о состоянии рабочего процесса и ограничениях правил
Правила рабочего процесса применяются при добавлении или изменении рабочих элементов с помощью любого из следующих интерфейсов:
- Веб-портал: форма рабочего элемента, массовые обновления, обновления в представлении запросов
- Веб-портал: доска или панель задач, перемещение рабочего элемента в столбец
- Форма рабочего элемента Visual Studio 2017 и более ранних версий
- Формат CSV-файла: массовый импорт или обновление
- Excel: массовый импорт или обновление
- REST API: добавление или изменение рабочих элементов
В следующей таблице описаны состояние рабочего процесса и ограничения правил для процесса наследования.
Объект | Ограничение на наследование |
---|---|
Типы рабочих элементов, определенные для процесса | 64 |
Состояния рабочего процесса, определенные для типа рабочего элемента | 32 |
Правила, определенные для типа рабочего элемента | 1024 |
При определении состояний и правил рабочего процесса следуйте этим рекомендациям, чтобы свести к минимуму проблемы с производительностью:
- Ограничить количество правил для WIT: хотя можно создать несколько правил для типа рабочего элемента (WIT), дополнительные правила могут отрицательно повлиять на производительность при добавлении или изменении рабочих элементов. Система проверяет все правила, связанные с полями для типа рабочего элемента, когда пользователи сохраняют рабочие элементы. В некоторых случаях выражение проверки правила может стать слишком сложным для оценки SQL.
- Ограничить количество типов настраиваемых рабочих элементов: сокращение числа типов настраиваемых рабочих элементов может помочь обеспечить оптимальную производительность.
Определение правила
Прежде чем определить правило на основе состояний рабочего процесса, убедитесь, что следующие элементы находятся на месте:
- Состояния рабочего процесса: определите состояния рабочего процесса, как описано в разделе "Настройка рабочего процесса".
- Настраиваемые поля: если для правила требуется настраиваемое поле, добавьте его в тип рабочего элемента, как описано в разделе "Добавление и управление полями".
- Группы безопасности. Если правило требует, чтобы группа безопасности предоставляла или ограничивать изменения, основанные на членстве пользователей или групп, определите группу безопасности, как описано в разделе "Добавление или удаление пользователей или групп", управление группами безопасности.
Дополнительные сведения об определении правил см. в разделе "Добавление настраиваемого правила".
Установка значения поля или создание поля только для чтения или обязательного
С помощью первой группировки правил можно указать одно или два условия и до 10 действий для каждого правила.
Пример обеспечения утверждения руководителя команды перед активной работой
В этом примере команды разработчиков хотят убедиться, что история пользователя не будет работать до тех пор, пока не будет утверждена руководителем команды. Используются состояния рабочего процесса по умолчанию с добавлением настраиваемого поля, утвержденного и группы безопасности, группы потенциальных клиентов группы.
Состояния рабочего процесса по умолчанию
Требования к правилу
Чтобы убедиться в утверждении перед активной работой, определите следующие правила:
- Требовать заполнение поля "Утвержденный по" , когда состояние перемещается из "Новое " в "Активный"
- Ограничение пользователей, не входящих в группу потенциальных клиентов группы, от заполнения поля "Утвержденный по"
- Снимите поле "Утвержденный по", когда состояние переходит в "Новое" или "Удалено"
Определения правил
Требования к правилу преобразуют следующие четыре определения правил.
Имя правила
Условие
Действия
Утверждено, очищено, когда новое
Когда 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 действий.
Примечание.
Для этой функции требуется обновление или более поздняя версия Azure DevOps Server 2020.1.
Пример ограничения переходов состояния и утвержденного состояния
Для пользовательской истории определены следующие состояния рабочего процесса. Новые, разрешенные и удаленные унаследованные состояния скрыты. Вместо этого используются предлагаемые, в обзоре и вырезанные состояния. Кроме того, определены еще три государства: исследование, проектирование и утверждение. Эти состояния должны следовать последовательности, как показано на следующем рисунке.
Без каких-либо ограничений пользователи могут перемещаться из одного государства в любое другое состояние как вперед, так и назад в рамках последовательности.
Требования к правилу
Чтобы поддерживать более контролируемый рабочий процесс, бизнес-группа решила установить правила, поддерживающие следующие переадресации и обратные переходы состояния на тип рабочего элемента user Story.
State | Правило перехода |
---|---|
Предложено | Может переходить только к исследованиям и сокращению |
Исследование | Может переходить только к конструктору и сокращению |
Проект | Может переходить только к исследованиям, утверждениям и сокращению |
Утвержденная | Может переходить только к конструктору, активному и вырезанным |
Активно | Может переходить только к просмотру |
На рассмотрении | Может переходить только на активный (больше работ), закрытый или вырезанный |
Закрытые | Может перейти к исследованиям, проектированию, активному, в рецензирование (позволяет в случаях, когда пользователь закрыл рабочий элемент в ошибке) |
Вырезать | может переходить только к предлагаемому |
Примечание.
При ограничении переходов состояния следует учитывать случаи, когда пользователь может переместить состояние в ошибке. Убедитесь, что пользователи могут восстановиться корректно.
Кроме того, бизнес-группа хочет применить следующие правила для обязательных полей:
- Требовать заполнение поля "Утвержденный по" при переходе состояния с "Утверждено" на "Активный".
- Разрешить только пользователям в группе авторизованных утверждающих заполнить поле "Утвержденный по ".
- Снимите поле "Утвержденный по" при переходе состояния на "Вырезать".
- Требуется, чтобы поле "Критерии принятия" заполнялось при переходе состояния на "Активный".
Определения правил
Чтобы реализовать ранее упомянутые ограничения, администратор процесса добавляет настраиваемое поле "Утвержденный по удостоверениям", группу безопасности авторизованных утверждающих и следующие правила.
Имя правила
Условие
Действия
Предлагаемое состояние
Когда 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
Проверка ограничений перехода состояния
После определения правил процесса и обновления проекта обновите браузер. Проверьте операции с помощью формы рабочего элемента и браузера.
Для правил, определенных в предыдущей таблице, проверьте раскрывающееся меню состояния. Откройте доску и убедитесь, что вы можете перейти из одного состояния в другое.
Предложенный | Исследование | Проектирование | Одобренный |
---|---|---|---|
Активные | В обзоре | Закрытые | Вырезать |
Ограничение перехода состояния на основе членства пользователей или групп
При указании одного из двух условий на основе членства Current user is member of group ...
Current user is not member of group ...
пользователей или групп можно указать только одно условие. Кроме того, если указать действие Restrict the transition to state...
, можно указать только одно действие.
Примечание.
Рабочие элементы применяются к ним правилам. Условные правила на основе членства пользователей или групп кэшируются в веб-браузере. Если вы нашли себя ограниченным для обновления рабочего элемента, возможно, вы столкнулись с одним из этих правил. Если вы считаете, что вы столкнулись с проблемой, которая не применяется к вам, см . статью "Проблемы с кэшированием в форме рабочего элемента IndexDB".
Автоматизация переходов состояния родительских рабочих элементов
Чтобы автоматизировать переходы состояния для родительских рабочих элементов, основанных на назначениях состояния дочерних рабочих элементов, см. в статье "Автоматизация переходов состояния рабочего элемента".
Автоматизация переназначения на основе изменения состояния
Ранее тип рабочего элемента с ошибкой гибкого процесса имел правило, которое переназначило ошибку своему создателю. Мы удалили это правило из системного процесса по умолчанию. Можно восстановить правило или добавить аналогичное правило другим типам рабочих элементов с помощью следующего условия и действия:
При A work item state changes to
разрешенииCopy the value from
, созданном для назначения.