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

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

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

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

Процесс наследования

Локальный XML-процесс

Вы указываете WHEN инструкцию правила для определения поля в FIELDS разделе определения типа рабочего элемента.

<FIELDS>
   ...
   <FIELD refname="MyCorp.Severity" name="Customer Severity" type="String">  
       <ALLOWEDVALUES>  
           <LISTITEM value="Blocking" />  
           <LISTITEM value="Major" />  
           <LISTITEM value="Minor" />  
       </ALLOWEDVALUES>  
       <WHEN field="MyCorp.CustomerReported" value="true">  
           <REQUIRED />  
       </WHEN>  
   </FIELD> 
   ...
</FIELDS>     

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

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

Процесс наследования

Локальный XML-процесс

Вы указываете WHENCHANGED инструкцию правила для определения поля в FIELDS разделе определения типа рабочего элемента.

<FIELDS>
 ...
   <FIELD name="Story Points" refname="Microsoft.VSTS.Scheduling.StoryPoints" type="Double" reportable="measure" formula="sum">
       <HELPTEXT>The size of work estimated for implementing this user story</HELPTEXT>
       <WHENCHANGED field="Microsoft.VSTS.Scheduling.StartDate">  
           <EMPTY />  
       </WHENCHANGED>
   </FIELD>
   ...
</FIELDS>     

Установка значения зависимого поля

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

Процесс наследования

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

Диалоговое окно "Изменение поля" для поля "Размер рубашки"

Настраиваемое правило

Четыре пользовательских правила

Локальный XML-процесс

Укажите значение поля Size в FIELDS разделе определения типа рабочего элемента. Для сопоставления используется ряд инструкций WHEN правил, задав значение поля Size с помощью COPY value="value" правила.

<FIELDS>
   ...
   <FIELD name="Tee-Shirt Size" refname="Fabrikam.TShirt.Size" type="String">
        <HELPTEXT>Estimate of overall size for work to be done; Small (2), Medium (6), Large (18), X-Large (30).</HELPTEXT>
        <ALLOWEDVALUES expanditems="true">
          <LISTITEM value="Large" />
          <LISTITEM value="Medium" />
          <LISTITEM value="Small" />
          <LISTITEM value="X-Large" />
        </ALLOWEDVALUES>
   </FIELD> 
   <FIELD name="Size" refname="Fabrikam.Size" type="Integer">
        <HELPTEXT>Integer estimate of overall size for work to be done; Automatically fill in based on Tee-Shirt Size. Allow any value.</HELPTEXT>
        <WHEN field="Fabrikam.TShirt.Size" value="Small">
          <COPY value="2" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Medium">
          <COPY value="6" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Large">
          <COPY value="18" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="X-Large">
          <COPY value="30" />
        </WHEN>
   </FIELD>
   ...
 </FIELDS> 

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

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

Процесс наследования

Локальный XML-процесс

Если для рабочего элемента задано значение "Состояние", а рабочий элемент сохраняется, значения полей "Активировано по" и "Назначено для" автоматически задаются в качестве имени текущего пользователя. Этот пользователь должен быть членом группы допустимых пользователей Team Foundation Server. Значение поля "Активированная дата " также устанавливается автоматически. В следующем примере показаны элементы, которые применяют это правило:

<WORKFLOW>
. . .  
    <STATE value="Active">
        <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <REQUIRED />
            </FIELD>
        </FIELDS>
    </STATE>
. . .  
</WORKFLOW>

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

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

Процесс наследования

Локальный XML-процесс

<WORKFLOW>
. . .  
      <STATE value="Closed">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <EMPTY />
            </FIELD>
          </FIELDS>
      </STATE>
. . .  
</WORKFLOW>

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

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

Процесс наследования

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

Локальный XML-процесс

Следующее настраиваемое правило ограничивает команду проверки Fabrikam (для атрибута) от создания рабочих элементов, разрешая переход к новому состоянию рабочего процесса.

<WORKFLOW>
... 
<TRANSITION from=" " to="New"  
   for="[Project]\Developers" 
   not="[Project]\Fabrikam Review Team"  
   . . .  
</TRANSITION> 
...  
</WORKFLOW>

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

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

Процесс наследования

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

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

Локальный XML-процесс

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

<WORKFLOW>
... 
 <STATE value="New">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Active">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Resolved">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Closed">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
...  
</WORKFLOW>

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

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

Совет

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

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

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

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

Процесс наследования

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

Примечание.

Условие A work item state moved from ... доступно для Azure DevOps Server 2020 и более поздних версий.

Примечание.

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

Локальный XML-процесс

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

<WORKFLOW>
. . .  
<TRANSITION from="Closed" to="New"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
. . .  
</WORKFLOW>

Скрытие или ограничение изменения поля на основе пользователя или группы

При выборе Current user is a member of group... или Current user is not a member of group...скрытии поля можно сделать поле только для чтения или сделать поле обязательным.

Например, следующее условие указывает, что поле "Обоснование" скрыто для членов, которые не принадлежат группе Fabrikam Fibre\Voice.

Примечание.

Рабочие элементы применяются к ним правилам. Условные правила на основе членства пользователей или групп кэшируются в веб-браузере. Если вы нашли себя ограниченным для обновления рабочего элемента, возможно, вы столкнулись с одним из этих правил. Если вы считаете, что вы столкнулись с проблемой, которая не применяется к вам, см . статью "Проблемы с кэшированием в форме рабочего элемента IndexDB".

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

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

Процесс наследования

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

• 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. Когда пользователь этой группы открывает историю пользователя, он не может изменить значение в поле "Приоритет".

Локальный XML-процесс

Для локальной модели xml-процессов можно настроить типы рабочих элементов для поддержки этих запросов ограничений:

• Ограничение того, кто может создать или изменить рабочий элемент
• Ограничение того, кто может создавать определенные типы рабочих элементов, например Epics или Features

Например, можно ограничить изменение рабочих элементов, добавив правило в тип рабочего элемента, обычно в разделе WORKFLOW .

Вы ограничиваете доступ к объектам отслеживания работы одним из двух способов:

• Задайте правило поля условия, правило поля на основе условий или сочетание двух, которые применяются к группе. Вы можете ограничить внесение изменений в поле, указав соответствующее правило и сделав его применимым для определенной группы. Условные правила могут включать элементы NOTLOSEVALUE, EMPTY, FROZEN, NOTSAMEAS, READONLY и REQUIRED.
• Добавив WIT в группу скрытых категорий, вы можете предотвратить создание большинства участник проекта. Вы можете создать гиперссылку на шаблон , который открывает форму рабочего элемента и поделиться этой ссылкой с теми участниками группы, которые вы хотите создать.

Связанные статьи

• Применение правил к состояниям рабочего процесса (процесс наследования)
• Правила и оценка правил