Применение правил к состояниям рабочего процесса (процесс наследования)
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
После добавления или изменения состояний рабочего процесса для типа рабочего элемента может потребоваться определить одно или несколько правил, применяемых в зависимости от изменения состояния рабочего процесса. Добавление правил в состояния рабочего процесса поддерживает следующие сценарии:
- Поддержка процесса утверждения
- Запретить несанкционированным пользователям устанавливать недопустимое состояние
- Сделайте поле обязательным или только для чтения или другим значением на основе изменений состояния
- Ограничение перехода от одного состояния к другому
- Ограничение или разрешение переходов состояния на определенных пользователей или групп
- Обслуживание управляемого процесса рабочего процесса для поддержки требований аудита
- Автоматизация закрытия родительских рабочих элементов
- Поддержка процесса утверждения
- Запретить несанкционированным пользователям устанавливать недопустимое состояние
- Сделайте поле обязательным или только для чтения или другим значением на основе изменений состояния
- Ограничение перехода от одного состояния к другому
- Автоматизация закрытия родительских рабочих элементов
- Поддержка процесса утверждения
- Сделайте поле обязательным или только для чтения или другим значением на основе изменений состояния
- Автоматизация закрытия родительских рабочих элементов
Ознакомьтесь с этой статьей, чтобы понять, как определить правила, применяемые при изменении состояния рабочего процесса.
- Общие сведения о типах правил рабочего процесса
- Ограничения состояния рабочего процесса и правила и рекомендации
- Задайте значение поля или сделайте поле доступным только для чтения или обязательным на основе выбора состояния
- Ограничение переходов состояния
- Ограничение или разрешение переходов состояния на определенных пользователей или групп
- Автоматизация переходов состояния родительских рабочих элементов
- Общие сведения о типах правил рабочего процесса
- Ограничения состояния рабочего процесса и правила и рекомендации
- Задайте значение поля или сделайте поле доступным только для чтения или обязательным на основе выбора состояния
- Ограничение переходов состояния
- Автоматизация переходов состояния родительских рабочих элементов
- Общие сведения о типах правил рабочего процесса
- Ограничения состояния рабочего процесса и правила и рекомендации
- Задайте значение поля или сделайте поле доступным только для чтения или обязательным на основе выбора состояния
- Автоматизация переходов состояния родительских рабочих элементов
Внимание
Модель процесса наследования доступна для проектов, настроенных для поддержки. Если вы используете старую коллекцию, проверьте совместимость модели процесса. Если локальная коллекция настроена на использование локальной модели xml-процессов, можно использовать только эту модель процесса для настройки интерфейса отслеживания работы. Дополнительные сведения см. в разделе "Выбор модели процесса" для коллекции проектов.
Правила рабочего процесса
В следующей таблице указаны три группы правил рабочего процесса, которые можно определить. Первая группа применяет стандартные действия при создании рабочего элемента в выбранном состоянии или перемещается из одного состояния в другое. Эти стандартные действия задают значение поля или делают поле доступным только для чтения или обязательным. В этой группе можно указать одно или два условия и несколько действий.
Второй и третий группы поддерживают ограничение переходов состояния. Эти две группы позволяют указать одно и только одно условие, указывающее состояние, в которое перемещен рабочий элемент. Затем можно указать одно или несколько действий, чтобы ограничить переход с этого состояния на другие состояния.
В следующей таблице указаны две группы правил рабочего процесса, которые можно определить. Первая группа применяет стандартные действия при создании рабочего элемента в выбранном состоянии или перемещается из одного состояния в другое. Эти стандартные действия задают значение поля или делают поле доступным только для чтения или обязательным. В этой группе можно указать одно или два условия и несколько действий.
Вторая группа поддерживает ограничение переходов состояния. В этой второй группе можно указать одно и только одно условие, указывающее состояние, в которое перемещен рабочий элемент. Затем можно указать одно или несколько действий, чтобы ограничить переход с этого состояния на другие состояния.
Примечание.
Для некоторых функций требуется установка обновления Azure DevOps Server 2020.1. Дополнительные сведения см. в заметках о выпуске Azure DevOps Server 2020 с обновлением 1 RC1, досках.
Условия рабочего процесса и действия, которые можно задать, показаны на следующих изображениях. Стандартные действия можно применять при создании рабочего элемента в выбранном состоянии или перемещении из одного состояния в другое. Эти стандартные действия задают значение поля или делают поле доступным только для чтения или обязательным. Для этого набора правил можно указать одно или два условия и несколько действий.
Условие
Поддерживаемые действия
Установка значения поля или создание только для чтения или обязательного использования в зависимости от состояния
Ограничение перехода на основе состояния
Скрытие поля или создание поля только для чтения или обязательного на основе состояния и членства пользователей или групп
На основе членства пользователей или групп задайте атрибут поля или ограничьте переход состояния
Примечание.
При настройке унаследованного процесса все проекты, использующие этот процесс, автоматически отражают настройки. Чтобы обеспечить плавный переход, рекомендуется создать тестовый процесс и проект, который позволяет протестировать настройки перед их реализацией на уровне организации. Дополнительные сведения см. в разделе "Создание унаследованных процессов и управление ими".
Ограничения состояния рабочего процесса и правила
В следующей таблице описаны состояние рабочего процесса и ограничения правил для процесса наследования.
Объект | Ограничение на наследование |
---|---|
Типы рабочих элементов, определенные для процесса | 64 |
Состояния рабочего процесса, определенные для типа рабочего элемента | 32 |
Правила, определенные для типа рабочего элемента | 1024 |
При определении состояний и правил рабочего процесса рекомендуется учитывать следующие рекомендации, чтобы свести к минимуму проблемы с производительностью.
- Свести к минимуму количество правил, которые вы определяете для WIT. Хотя для типа рабочего элемента можно создать несколько правил, это может негативно повлиять на производительность при добавлении и изменении рабочих элементов пользователем. Когда пользователи сохраняют рабочие элементы, система проверяет все правила, связанные с полями для типа рабочего элемента. При определенных условиях выражение проверки правила будет слишком сложным для вычисления SQL.
- Свести к минимуму количество типов настраиваемых рабочих элементов.
Правила рабочего процесса применяются при добавлении или изменении рабочих элементов с помощью любого из следующих интерфейсов:
- Веб-портал: форма рабочего элемента, массовые обновления, обновления в представлении запросов
- Веб-портал: доска или панель задач, перемещение рабочего элемента в столбец
- Форма рабочего элемента Visual Studio 2017 и более ранних версий
- Формат CSV-файла: массовый импорт или обновление
- Excel: массовый импорт или обновление
- REST API: добавление или изменение рабочих элементов
Определение правила
Перед определением правила на основе состояний рабочего процесса определите следующие элементы:
- Рабочий процесс указывает, что требуется, как описано в разделе "Настройка рабочего процесса"
- Если для правила требуется спецификация настраиваемого поля, добавьте это поле в тип рабочего элемента, как описано в разделе "Добавление и управление полями"
- Если для правила требуется спецификация группы безопасности для предоставления или ограничения изменений на основе членства пользователей или групп, определите эту группу безопасности, как описано в разделе "Добавление или удаление пользователей или групп", управление группами безопасности.
Основы определения правил см. в разделе "Добавление настраиваемого правила". Необходимо выполнить необходимые условия, определенные в этой статье.
Установка значения поля или создание поля только для чтения или обязательного
С помощью первой группировки правил можно указать одно или два условия и до 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.
Пример ограничения переходов состояния и утвержденного состояния
Для пользовательской истории определены следующие состояния рабочего процесса. Новые, разрешенные и удаленные унаследованные состояния скрыты. Вместо этого используются предлагаемые, в обзоре и вырезанные состояния. Кроме того, определены еще три государства: исследование, проектирование и утверждение. Эти состояния должны следовать последовательности, как показано на следующем рисунке.
Без каких-либо ограничений пользователи могут перемещаться из одного государства в любое другое состояние как вперед, так и назад в рамках последовательности.
Требования к правилу
Чтобы поддержать более контролируемый рабочий процесс, бизнес-группа решила установить правила, которые будут поддерживать следующие переходы вперед и обратного состояния на тип рабочего элемента "История пользователя".
- Предлагаемое предложение может перейти только к исследованиям и сокращению
- Исследования могут переходить только к проектированию и сокращению
- Проектирование может переходить только на исследования, утвержденные и вырезанные
- Утвержденные могут перемещаться только в конструктор, активный и вырезанный
- Активные могут переходить только на "Просмотр"
- В разделе "Рецензирование " можно перейти только на активный (больше трудоемких работ), "Закрыть " или "Вырезать"
- Закрытый может перейти к исследованию, проектированию, активному, в рецензирование (позволяет в случаях, когда пользователь закрыл рабочий элемент в ошибке)
- Вырезка может переходить только к предлагаемому.
Примечание.
При ограничении переходов состояния учитывайте те случаи, когда пользователь перемещает состояние в ошибке. Вы хотите, чтобы пользователи могли эффективно восстанавливаться.
Кроме того, бизнес-группа хочет применить правила для обязательных полей:
- Требовать заполнение поля "Утвержденный по", когда государство переходит от "Утверждено" к активному
- Разрешить пользователям, принадлежащим группе авторизованных утверждающих, заполнить поле "Утвержденный по"
- Очистка поля "Утвержденный по" при переходе состояния на "Вырезать"
- Требовать заполнение условий принятия, когда состояние переходит в активный
Определения правил
Для реализации указанных выше ограничений администратор процесса добавляет настраиваемое поле "Утвержденный по удостоверениям", группу безопасности авторизованных утверждающих и следующие 11 правил.
Имя правила
Условие
Действия
Предлагаемое состояние
Когда 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
, созданном для назначения.
Связанные статьи
Примечание.
Просмотрите изменения, внесенные в унаследованный процесс через журнал аудита. Дополнительные сведения см. в статьях "Доступ", "Экспорт" и "Фильтрация журналов аудита".