Примеры сценариев настраиваемых правил
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
В этой статье приведены примеры пользовательских определений правил. Все пользовательские правила определяются для типа рабочего элемента. Примеры приведены для моделей наследуемых процессов и локальных XML-процессов.
Перед добавлением настраиваемых правил считывать правила и оценку правил и добавлять правило в тип рабочего элемента (процесс наследования).
Определение зависимых обязательных полей
Можно указать, что поле является обязательным, только если другое поле содержит определенное значение. В следующем примере, когда клиент сообщает о проблеме, настраиваемое поле "Сообщается о клиенте" имеет значение True, а поле "Серьезность " становится обязательным. Если проблема не сообщается клиентом, значение поля "Серьезность " не требуется.
Очистка значения зависимого поля
В следующем примере показано определение настраиваемого правила для очистки значения для точек истории при изменении даты начала.
Установка значения зависимого поля
В следующих примерах показано, как сопоставить значения поля Size в зависимости от значения, выбранного для настраиваемого поля , tee-Shirt Size поля.
Список выбора размера tee-shirt состоит из четырех значений Small, Medium, Large и X-Large. Четыре настраиваемых правила определяются для назначения поля "Размер" при изменении поля "Размер рубашки" на определенное значение. Чтобы упростить использование, значение по умолчанию для размера tee-shirt имеет значение Small.
Диалоговое окно "Изменение поля" для поля "Размер рубашки"
Настраиваемое правило
Четыре пользовательских правила
Требовать значение поля при изменении состояния
В следующем примере показано, как можно требовать спецификацию поля "Оставшаяся работа", когда состояние рабочего процесса задачи изменяется на "Активный".
Очистка значения поля при закрытии состояния
Чтобы автоматизировать очистку поля оставшихся работ при закрытии задачи, определите настраиваемое правило, как указано.
Ограничение создания рабочих элементов по группе
Пользовательское правило, ограничивающее переход на категорию предлагаемого состояния типа рабочего элемента, фактически запрещает создание рабочих элементов этого типа. Применяя правило к определенной группе, вы фактически запрещаете эту группу создавать рабочие элементы этого типа.
Следующее настраиваемое правило ограничивает группу проектов создавать рабочие элементы, так как категория "Предлагаемое состояние" сопоставляется с новым состоянием рабочего процесса.
Ограничение изменения рабочих элементов по группе
Для процесса наследования можно запретить пользователям изменять рабочий элемент, задав разрешение на запрет группы в пути к области. Для локального XML-процесса можно поместить ограничения на каждое состояние рабочего процесса для группы, которая предотвращает сохранение рабочего элемента в любом состоянии.
Невозможно определить пользовательское правило, ограничивающее изменение рабочих элементов определенного типа. Можно указать только ограничение по состоянию. Если пользователь не изменяет состояние, он может изменить другие поля, если только все поля не будут доступны только для чтения для группы.
Вместо этого, если вы хотите ограничить группу пользователей изменением рабочих элементов любого типа, можно назначить эти рабочие элементы пути области. Определите группу безопасности и задайте ограничения для редактирования рабочих элементов для этой группы, как показано на следующем рисунке. Дополнительные сведения см. в разделе "Настройка разрешений и доступа для отслеживания работы", создание дочерних узлов и изменение рабочих элементов в пути к области
Ограничение переходов состояния
Для наследуемых процессов автоматически определяются переходы состояния "любой к любому". Это позволяет пользователям продвинуть состояние рабочего процесса от нового до завершения, но и переместить назад в случае необходимости. При определении пользовательских правил ограничения перехода следует помнить, что если пользователь ошибается при обновлении рабочего процесса, он может не исправить его. Например, они могут обновить состояние, переместив карточку рабочего элемента на более поздний этап на доске, но не переместив ее обратно.
Совет
Рассмотрите возможность ограничения перехода состояния для некоторых пользователей, но не всех пользователей. Таким образом, если пользователь ошибается, он может попросить другого члена команды сбросить значение State, чтобы обойти ограничение.
Перед определением правил перехода состояния просмотрите правила и оценку правил, автоматически созданные правила и способы использования состояний рабочих процессов и категорий состояний в невыполненных работах и досках.
Ограничение изменения закрытых рабочих элементов
В зависимости от бизнес-процессов может потребоваться запретить пользователям продолжать изменять или обновлять рабочие элементы, которые были закрыты или завершены. Вы можете добавить правила в типы рабочих элементов, чтобы запретить пользователям повторно открывать закрытые рабочие элементы.
Для унаследованного процесса можно добавить правило, ограничивающее переход состояния. Например, следующее правило ограничивает переход с закрытого на два других состояния, New и Active.
Примечание.
Условие 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.
Примечание.
Рабочие элементы применяются к ним правилам. Условные правила на основе членства пользователей или групп кэшируются в веб-браузере. Если вы нашли себя ограниченным для обновления рабочего элемента, возможно, вы столкнулись с одним из этих правил. Если вы считаете, что вы столкнулись с проблемой, которая не применяется к вам, см . статью "Проблемы с кэшированием в форме рабочего элемента IndexDB".
Ограничение изменения выбранных полей на основе пользователя или группы
Вы можете настроить типы рабочих элементов, чтобы ограничить, кто может изменить определенное поле для типа рабочего элемента.
Примечание.
Для Azure DevOps Server 2019 и более ранних версий можно ограничить только изменение рабочих элементов на основе пользователя или группы с помощью локальной модели процесса XML.
Используя одно из следующих двух условий, можно сделать поля, необходимые для пользователя группы безопасности или не являющегося членом группы безопасности.
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. Когда пользователь этой группы открывает историю пользователя, он не может изменить значение в поле "Приоритет".
