Примеры сценариев настраиваемых правил

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 — TFS 2013

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

Перед добавлением пользовательских правил, чтения правил и оценки правил , а затем Добавьте правило в тип рабочего элемента (процесс наследования).

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

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

Снимок экрана с пользовательским правилом для обеспечения серьезности, когда поле сообщило клиенту = true.

Очистить значение зависимого поля

В следующем примере показано определение настраиваемого правила для очистки значения для точек истории при внесении изменений в дату начала.

Снимок экрана настраиваемого правила для очистки значения баллов истории при изменении даты начала.

Задание значения зависимого поля

В следующих примерах показано, как сопоставлять значения поля size в зависимости от значения, выбранного для поля Размер настраиваемого поля, tee .

Список выбора размера рубашки tee состоит из четырех значений: малый, средний, крупныйи X-крупный. Для назначения поля размера при изменении значения поля размера tee-рубашки на определенное значение определяются четыре настраиваемых правила. Чтобы упростить использование, значение по умолчанию для размера tee-рубашкиневелико.

Диалоговое окно "изменение поля" для поля "размер Tee-Shirt"

Снимок экрана: диалоговое окно редактирования поля для Tee-Shirt размера поля.

Пользовательское правило

Снимок экрана настраиваемого правила для установки значения размера, если Tee-Shirt установлен маленький размер.

Четыре настраиваемых правила

Снимок экрана: четыре настраиваемого правила для установки значения размера при задании размера Tee-Shirt.

Требовать значение поля при изменении состояния

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

Снимок экрана настраиваемого правила для выполнения оставшейся работы при изменении состояния на

Очистить значение поля после закрытия состояния

Чтобы автоматизировать очистку поля Оставшиеся трудозатраты при закрытии задачи, определите пользовательское правило, как указано.

Снимок экрана пользовательского правила для нулевой оставшейся работы требуется при изменении состояния на

Ограничение создания рабочих элементов группой

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

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

Снимок экрана настраиваемого правила для ограничения создания рабочего элемента группой.

Ограничение изменения рабочих элементов группой

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

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

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

Снимок экрана: диалоговое окно разрешений для пути к области для ограничения изменений рабочих элементов.

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

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

Совет

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

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

Ограничение изменения закрытых рабочих элементов

В зависимости от бизнес-процессов может потребоваться запретить пользователям продолжать изменять или обновлять рабочие элементы, которые были закрыты или завершены. Можно добавить правила в типы рабочих элементов, чтобы запретить пользователям повторно открывать закрытые рабочие элементы.

Для наследуемого процесса можно добавить правило, которое будет ограничивать смену состояния. Например, следующее правило ограничит переход от закрытого к другим двум состояниям, 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 Фибер\воице.

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

Примечание

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

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

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

Примечание

для Azure DevOps Server 2019 и более ранних версий можно ограничить только изменение рабочих элементов на основе пользователя или группы с локальной моделью процесса XML.

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

  • current user is a member of a group...
  • current user is not a member of a group...

Совет

чтобы избежать проблем с оценкой правил, укажите Azure DevOps группы безопасности, а не Azure Active Directory или Active Directory группы безопасности. Дополнительные сведения см. в разделе правила по умолчанию и обработчик правил.

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

Например, поле приоритет для типа рабочего элемента «история пользователя» доступно только для чтения для членов группы Fabrikam фибер\воице. Когда пользователь этой группы открывает пользовательскую историю, он не может изменить значение в поле приоритет.

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