Примеры сценариев настраиваемых правил
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
В этой статье приведены примеры пользовательских определений правил. Все пользовательские правила определяются для типа рабочего элемента. Примеры приведены для моделей наследуемых процессов и локальных XML-процессов.
Перед добавлением настраиваемых правил прочитайте «Правила и оценка правил» и «Добавление правила к типу рабочего элемента (процесс наследования)».
Определение зависимых обязательных полей
Можно указать, что поле является обязательным, только если другое поле содержит определенное значение. В следующем примере, когда клиент сообщает о проблеме, настраиваемое поле 'Сообщено клиентом' имеет значение True, а поле 'Серьезность' становится обязательным. Если проблема не сообщается клиентом, значение поля "Серьезность " не требуется.
Очистка значения зависимого поля
В следующем примере показано определение настраиваемого правила для очистки значения для точек истории при изменении даты начала.
Установка значения зависимого поля
В следующих примерах показано, как сопоставляются значения поля Size в зависимости от значения, выбранного для настраиваемого поля Tee-Shirt Size.
Список выбора размера tee-shirt состоит из четырех значений Small, Medium, Large и X-Large. Четыре настраиваемых правила определяются для назначения поля "Размер" при изменении поля "Размер рубашки" на определенное значение. Чтобы упростить использование, значение по умолчанию для размера футболки — маленький.
Диалоговое окно "Изменение поля" для поля "Размер рубашки"
Настраиваемое правило
Четыре пользовательских правила
Требовать значение поля при изменении состояния
В следующем примере показано, как можно требовать спецификацию поля "Оставшаяся работа", когда состояние рабочего процесса задачи изменяется на "Активный".
Очистка значения поля при закрытии состояния
Чтобы автоматизировать очистку поля оставшихся работ при закрытии задачи, определите настраиваемое правило, как указано.
Ограничить создание рабочих элементов группой
Пользовательское правило, ограничивающее переход на категорию предлагаемого состояния типа рабочего элемента, фактически запрещает создание рабочих элементов этого типа. Применяя правило к определенной группе, вы фактически запрещаете эту группу создавать рабочие элементы этого типа.
Следующее настраиваемое правило ограничивает группу проектов создавать рабочие элементы, так как категория "Предлагаемое состояние" сопоставляется с новым состоянием рабочего процесса.
Ограничение изменения рабочих элементов по группе
Для процесса наследования можно запретить пользователям изменять рабочий элемент, установив запрет на разрешения для группы в пути области. Для локального XML-процесса можно поместить ограничения на каждое состояние рабочего процесса для группы, которая предотвращает сохранение рабочего элемента в любом состоянии.
Невозможно определить пользовательское правило, ограничивающее изменение рабочих элементов определенного типа. Можно указать только ограничение по состоянию. Если пользователь не изменяет состояние, он может изменить другие поля, если только все поля не будут доступны только для чтения для группы.
Вместо этого, если вы хотите ограничить группу пользователей от изменения выбранных рабочих элементов любого типа, можно назначить эти рабочие элементы определенному пути области. Определите группу безопасности, а затем установите ограничения на редактирование рабочих элементов для этой группы в указанном маршруте области, как показано на следующем рисунке. Для получения дополнительной информации см. "Установить разрешения и доступ для отслеживания работы", создание дочерних узлов и изменение рабочих элементов в рамках пути области
Ограничение переходов состояния
Для наследуемых процессов автоматически определяются переходы состояний из любого состояния в любое другое состояние. Это позволяет пользователям продвинуть состояние рабочего процесса от нового до завершения, но и переместить назад в случае необходимости. При определении пользовательских правил ограничения перехода следует помнить, что если пользователь ошибается при обновлении рабочего процесса, он может не исправить его. Например, они могут обновить состояние, переместив карточку рабочего элемента на более поздний этап на доске, но не переместив ее обратно.
Совет
Рассмотрите возможность ограничения перехода состояния для некоторых пользователей, но не всех пользователей. Таким образом, если пользователь совершает ошибку, он может попросить другого члена команды сбросить значение State, чтобы обойти ограничение.
Перед определением правил перехода состояния, просмотрите Правила и оценка правил, Автоматически созданные правила и Как состояния рабочих процессов и категории состояний используются в Невыполненных работах и Досках.
Ограничьте изменение закрытых рабочих элементов
В зависимости от бизнес-процессов может потребоваться запретить пользователям продолжать изменять или обновлять рабочие элементы, которые были закрыты или завершены. Вы можете добавить правила в типы рабочих элементов, чтобы запретить пользователям повторно открывать закрытые рабочие элементы.
Для наследуемого процесса можно добавить правило, ограничивающее переход состояния. Например, следующее правило ограничивает переход из состояния "Закрыто" в два других состояния: "Новое" и "Активное".
Примечание.
Условие A work item state moved from ... доступно для Azure DevOps Server 2020 и более поздних версий.
Примечание.
В зависимости от указанного действия правила может быть отключена кнопка "Сохранить " в форме рабочего элемента, или сообщение об ошибке отображается при попытке ограниченного пользователя изменить рабочий элемент.
Скрытие или ограничение изменения поля на основе пользователя или группы
При выборе Current user is a member of group... или Current user is not a member of group... можно скрыть поле, сделать поле только для чтения или сделать его обязательным.
Например, следующее условие указывает, что поле "Обоснование" скрыто для членов, которые не принадлежат группе Fabrikam Fibre\Voice.
Примечание.
Рабочие элементы подлежат правилам, применяемым к ним. Условные правила на основе членства пользователей или групп кэшируются в веб-браузере. Если вы нашли себя ограниченным для обновления рабочего элемента, возможно, вы столкнулись с одним из этих правил. Если вы считаете, что столкнулись с проблемой, которая к вам не относится, см.
Ограничение изменения выбранных полей на основе пользователя или группы
Вы можете настроить типы рабочих элементов, чтобы ограничить, кто может изменить определенное поле для типа рабочего элемента.
Используя одно из следующих двух условий, можно сделать поля обязательными для пользователя, который является членом группы безопасности, или не является членом группы безопасности.
current user is a member of a group...current user is not a member of a group...
Совет
Чтобы избежать проблем с оценкой правил, которые могут возникнуть, укажите группы безопасности Azure DevOps, а не группы безопасности Microsoft Entra ID или Active Directory. Дополнительные сведения см. в разделе "Правила по умолчанию" и обработчик правил.
Например, можно сделать поля Заголовок или Состояниетолько для чтения для некоторых пользователей или групп.
Например, поле "Приоритет " для типа рабочего элемента "История пользователя" становится доступным только для чтения для членов группы Fabrikam Fibre\Voice. Когда пользователь этой группы открывает историю пользователя, он не может изменить значение в поле "Приоритет".
