Правила и их оценка

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

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

Вы определяете пользовательские правила для поддержки бизнес-вариантов использования. В зависимости от типа данных поля можно задать разные ограничения для вводимых в этом поле данных. Можно указать значения для списка выбора (раскрывающееся меню), задать значения по умолчанию, очистить записи или ограничить внесение изменений. Используя условные правила, можно применять правила к полю на основании зависимостей между значениями разных полей. Кроме того, можно ограничить набор пользователей, которым разрешено изменять поле, либо установить в качестве области действия правила некоторую группу.

Ознакомьтесь с этой статьей, чтобы понять следующее:

• Как система применяет автоматически созданные правила
• Ограничения, связанные с определением пользовательских правил в системных полях
• Различные типы настраиваемых правил, которые можно применить
• Как вычисляются правила
• Разница между правилами, определенными для процесса наследования, и локальным XML-процессом
• Почему необходимо свести к минимуму количество определяемых пользовательских правил.

Прежде чем определять пользовательские правила, ознакомьтесь со статьей "Настройка и настройка Azure Boards", чтобы получить общее представление о том, как настроить Azure Boards в соответствии с потребностями бизнеса.

Совет

Свести к минимуму количество правил, которые вы определяете для WIT. Хотя для типа рабочего элемента можно создать несколько правил, это может негативно повлиять на производительность при добавлении и изменении рабочих элементов пользователем. Когда пользователи сохраняют рабочие элементы, система проверяет все правила, связанные с полями для типа рабочего элемента. При определенных условиях выражение проверки правила будет слишком сложным для вычисления SQL.

Автоматически созданные правила

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

Правила перехода состояния

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

Для локальных процессов XML необходимо указать допустимые переходы в WORKFLOW разделе определения типа рабочего элемента.

Переходы состояния и правила полей "По дате"

Поля by/Date соответствуют полям", "Созданные по/дате", "Активированы по дате", "Разрешено по дате" и "Дата" и "Закрыта по дате".

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

К правилам и поведению по умолчанию, которые управляют этими полями, относятся:

1. Состояние "Закрыто" всегда содержится в категории "Завершено".
2. Категория завершенного состояния не настраивается и связана только с одним и только одним состоянием.
3. Это закрытое состояние всегда закрыто для процессов Agile и CMMI, а также всегда готово для процессов Scrum и Basic.
4. Автоматическое создание этих правил влияет на языковой стандарт, так как условие правила содержит имя состояния, локализованное. Система создает разные правила для разных языковых стандартов.
5. Автоматически созданные правила для этих полей указываются только для типов рабочих элементов, которые включают эти поля. Тип рабочего элемента может не включать один или несколько этих полей.
6. Эти правила необходимы, если тип рабочего элемента имеет пользовательские состояния, или тип рабочего элемента является пользовательским типом рабочего элемента.
7. Эти правила применяются только к унаследованным процессам; Они никогда не создаются для размещенных XML-процессов или локальных XML-процессов.

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

Правила полей даты изменения состояния

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

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

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

Между двумя процессами не существует сопоставления "один к одному". В некоторых случаях правило XML-элемента определяется в диалоговом окне "Изменить" для унаследованного процесса, а не как правило. Другие XML-элементы, такие как FROZEN, NOTSAMEASMATCHне поддерживаются в наследуемом процессе.

Обратите внимание на следующее:

• Правила всегда применяются, не только при взаимодействии с формой, но и при взаимодействии с другими средствами. Например, задание поля только для чтения применяется не только к форме рабочего элемента, но и через API и надстройку Azure DevOps Server в Excel.
• Наследуемые записи процесса указывают условия и действия для выполнения полного правила. XML-элементы не делают эти различия.
• Правила полей не поддерживают назначение значений, которые являются суммой двух других полей или выполнением других математических вычислений. Однако вы можете найти решение, которое соответствует вашим потребностям через расширение Marketplace Aggregator (веб-служба ) TFS. См. также свертка работы и других полей.
• Вы можете найти дополнительные решения для применения настраиваемых правил к полям с помощью расширений Marketplace, таких как расширение библиотеки элементов управления формами рабочих элементов.

Композиция правил

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

Для наследуемого процесса каждое правило состоит из двух частей: условий и действий. Условия определяют обстоятельства, которые должны выполняться для применения правила. Действия определяют выполняемые операции. Для большинства правил можно указать не более двух условий и 10 действий для каждого правила. Все пользовательские правила требуют выполнения всех условий.

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

   (Condition) When a work item State isАктивные
   (Condition) And when the value ofБизнес области значений =
   (Action) Then make requiredТочки истории

Примечание.

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

В следующей таблице перечислены действия, доступные с выбранными условиями.

Условие

Поддерживаемые действия

Установка значения поля или обязательное или доступное только для чтения

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

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

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

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

Примечание.

Элемент VALIDUSER не поддерживается для TFS 2018 и более поздних версий.

Где применить правило поля

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

Поля State (System.State) и Reason (System.Reason ) определяются в WORKFLOW разделе. Можно указать большинство правил полей для применения к полю во время изменения состояния, выбора причины или для определенного перехода. Дополнительные сведения см. в статье "Изменение рабочего процесса для типа рабочего элемента".

В противном случае укажите правило для вычисления только во время изменения состояния. Эти правила определяются в WORKFLOW разделе под элементом , REASONили TRANSITION элементамиSTATE. Все правила, за исключением HELPTEXT, могут применяться в элементе FIELD (Workflow).

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

• Правила, относящиеся к типу рабочего элемента, применяются независимо от расположения рабочего элемента в модели состояния. Например, <REQUIRED \> правило выполняет следующие проверка:

  "MyField Value" != NULL

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

  State field value == "MyState" && "MyField Value" != NULL

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

  State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState"
&& "MyField Value" != NULL

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

  Reason field == "MyReason" &&
State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

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

<STATE name="Active">
      <FIELDS>
      <FIELD refname="MyCorp.Severity" >
         <READONLY />
      </FIELD>
      </FIELDS>
</STATE>

Что происходит, если определены слишком много правил

Одно выражение SQL определяется для каждого проекта для проверки рабочих элементов всякий раз, когда они создаются или обновляются. Это выражение растет с числом правил, заданных для всех типов рабочих элементов, определенных для проекта. Каждый квалификатор поведения, указанный для поля, приводит к увеличению числа вложенных выражений. Вложенные правила, правила, которые применяются только к переходу или условию для значения другого поля, приводят к добавлению дополнительных условий в инструкцию IF . Когда выражение достигает определенного размера или сложности, SQL больше не может оценить его и создает ошибку. Удаление некоторых WIT или устранение некоторых правил может устранить ошибку.

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

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

Обход правил

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

Правила можно обойти одним из двух способов. Первый — через рабочие элементы — обновите REST API и задайте bypassRules для параметра значение true. Второй — это клиентская объектная модель, инициализировав в режиме обхода (инициализация WorkItemStore с WorkItemStoreFlags.BypassRules).

Системные поля и настраиваемые правила

Системные поля имеют System.Имена ссылок на имя, например System.Title и System.State.

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

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

• Можно сделать поля "Состояние " и "Причина " только для чтения.
• Большинство правил можно применять к полям Title, Assigned To, Description и Changed By.

Если вы не видите поле, указанное в раскрывающемся меню пользовательского интерфейса правила для процесса наследования, вот почему. Например, если вы пытаетесь создать путь к области (System.AreaPath) только для чтения на основе условия, поле "Путь к области" недоступен для выбора. Даже если вы можете указать системное поле, подсистема правил может ограничить сохранение правила.

Правила по умолчанию и копированию

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

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

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

Большинство этих действий правила можно применить с выбором любого условия.

Наследуемое действие процесса

Description

Copy the value from...

Указывает другое поле, содержащее значение, скопированное в текущее поле.

Clear the value of...

Очищает поле любого значения, содержащегося в нем.

Use the current time to set the value of ...

Задает время для поля на основе параметра времени текущего пользователя.

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

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

XML-элемент

Использование

COPY

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

<FIELD refname="MyCorp.Status" name="Status" type="String">  
   <COPY from="value" value=" " />  
</FIELD> 

DEFAULT

Указывает значение поля, пустого при создании или изменении рабочего элемента. Если поле уже имеет значение, DEFAULT правило игнорируется. Правила по умолчанию выполняются только в том случае, если Is значение поля в настоящее время пусто. Поддерживаемые значения включают текущее время (), текущего пользователя (from = "clock"from = "currentuser"), литеральное значение (from = "value" value = "literal") или значение другого поля (from = field field = "referenceNameField").

<FIELD refname="MyCorp.Priority" name="Priority" type="String" 
<HELPTEXT>Specify the severity of the problem</HELPTEXT 
   <ALLOWEDVALUES 
      <LISTITEM value="P1"/ 
      <LISTITEM value="P2"/ 
      <LISTITEM value="P3"/ 
   </ALLOWEDVALUES 
<DEFAULT from="value" value="P3"/ 
</FIELD 

SERVERDEFAULT

Указывает часы сервера или текущего пользователя, чтобы определить значение поля.

<TRANSITION from="New" to="Active">  
   <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.StartWork" />  
   </ACTIONS>  
   <REASONS>  
      <DEFAULTREASON value="Work started" />  
   </REASONS>  
   <FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
            <COPY from="currentuser" />  
            <VALIDUSER />  
            <REQUIRED />  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
         <SERVERDEFAULT from="clock" />  
      </FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser" />  
      </FIELD>  
   </FIELDS>  
</TRANSITION>  

Правила ограничения

Правила ограничения ограничивают изменение значения поля. Они определяют допустимые состояния для рабочего элемента. Каждое ограничение работает в одном поле. Ограничения оцениваются на сервере при сохранении рабочих элементов и если какое-либо ограничение нарушается, операция сохранения отклоняется.

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

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

Большинство этих действий правила можно применить с выбором любого условия.

Наследуемое действие процесса

Description

Hide the field...
Доступно только при выборе условия членства в группе.

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

Make read-only

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

Make required

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

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

XML-элемент

Использование

ALLOWEDVALUES

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

CANNOTLOSEVALUE

Запрещает пользователям очищать поле значения после указания значения. Этот элемент сохраняет текущее значение поля и не может быть очищен или пуст.

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <CANNOTLOSEVALUE /> 
</FIELD> 

FROZEN

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

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <FROZEN not="[Project]\Management Team" /> 
</FIELD> 

EMPTY

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

<FIELD refname="MyCorp.SubStatus" />  
   <WHEN field="MyCorp.Status" value="Approve" >  
     <EMPTY />
   </WHEN>  
</FIELD>  

MATCH

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

<FIELD refname="MyCorp.GitHubURL" name="GitHub URL" type="String">  
   <MATCH pattern="https:\/\/github\.com\/\S+[\.md|\.yml]$"/>  
</FIELD>

NOTSAMEAS

Предотвращает назначение поля тем же значением, что и для другого поля.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <NOTSAMEAS field="MyCorp.SubStatus" /> 
</FIELD> 

PROHIBITEDVALUES

Определяет список запрещенных значений для поля. Если несколько ALLOWEDVALUES и(или) PROHIBITEDVALUES правил применяются к конкретному полю, полный список допустимых значений является пересечением всех разрешенных списков значений ( или все, если нет разрешенных списков значений ( минус), то есть задать разницу — объединение всех запрещенных списков значений.

READONLY

Предотвращает изменение поля вообще. Это правило может потребоваться применить в определенных условиях. Например, после закрытия рабочего элемента необходимо сделать поле только для чтения, чтобы сохранить данные в целях создания отчетов.
Не используйте READONLY элемент EMPTY , так как EMPTY также делает поле только для чтения. Объединение этих элементов может привести к несогласованным результатам.
Кроме того, можно сделать поле доступным только для чтения из формы рабочего элемента с помощью атрибута Control элемента ReadOnly . Поле может быть записано другими клиентами, но не с помощью формы рабочего элемента.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <READONLY />  
</FIELD> 

REQUIRED

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

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <REQUIRED />  
</FIELD> 

Выбор списков

Списки выбора определяют значения, которые пользователь может или не может выбрать для поля String или Integer. Значения, определенные в списке выбора, отображаются в форме рабочего элемента и редакторе запросов.

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

Для наследуемого процесса списки выбора определяются в диалоговом окне "Изменение поля".

Диалоговое окно редактирования поля

Description

Вкладка "Определение " для поля списка выбора

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

Установите флажок "Разрешить пользователям вводить собственные значения" проверка box на вкладке "Параметры", чтобы разрешить пользователям указывать собственные записи.

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

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

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

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

XML-элемент

Description

ALLOWEDVALUES

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

ALLOWEXISTINGVALUE

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

PROHIBITEDVALUES

Определяет список запрещенных значений для поля.

SUGGESTEDVALUES

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

Поля удостоверений и ошибки проверки

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

<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
      <HELPTEXT>The user who is working on this work item</HELPTEXT>
      <ALLOWEXISTINGVALUE />
      <VALIDUSER />
      <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
      <LISTITEM value="Active" />
      <LISTITEM value="[project]\Contributors" />
      </ALLOWEDVALUES>
      <DEFAULT from="field" field="System.CreatedBy" />
</FIELD>

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

Условные правила указывают действие на основе значения поля, равного или не равного определенному значению, или если изменение было или не было сделано для значения определенного поля. Как правило, условные правила применяются сначала к безусловным правилам. Если для нескольких условных правил задано значение true, порядок выполнения : WhenNot, WhenChanged, WhenNotChanged.

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

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

Унаследованное условие

Description

The value of ... (equals) [Когда]

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

A change was made to the value of ... [WhenChanged]

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

The value of ... (not equals) [WhenNot]

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

No change was made to the value of ... [WhenNotChanged]

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

Унаследованное действие

Description

Clear the value of ...
Copy the value from ...
Make read-only ...
Make required ...
Set the value of ...
Use the current time to set the value of ...
Use the current user to set the value of ...

Указывает действие для выполнения определенного поля.

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

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

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

XML-элемент

Использование

WHEN

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

WHENCHANGED

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

WHENNOT

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

WHENNOTCHANGED

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

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

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

Реализация процесса

Совет

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

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

Как указано в следующей таблице, чтобы ограничить правило на основе членства текущего пользователя, укажите одно из двух условий для унаследованного процесса. Эти правила активны для Azure DevOps 2020 и более поздних версий.

Относится к

Правило

Condition

Current user is a member of group ...
Current user is not member of group ...

Действие

Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...

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

Чтобы ограничить правило на основе членства текущего пользователя, укажите fornot либо атрибуты в элементе правила. Вы указываете область правила. Чтобы правило область в несколько групп, необходимо создать родительскую группу Azure DevOps, содержащую набор групп, которые требуется использовать.

Сценарий

Использование

Создание поля, необходимого только для указанной группы

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

<FIELD name="Second Approver">
<REQUIRED for="Example1\Junior Analysts"/>
</FIELD>

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

Используется not для исключения группы из правила. В этом примере поле "Описание трижа" определяется как доступное только для чтения для всех, кроме тех пользователей в группе Triage Committee.

<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>

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

Используйте сочетание for и not одновременно применять правило к некоторым, а не для других. Этот пример определяет серьезность в качестве обязательного поля для пользователей в группе участников проекта, но не для пользователей группы Project Администратор s. Если пользователь находится в обеих группах, for инструкция будет применена, и поле будет обязательным.

<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>

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

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

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

Ниже приведены примеры маркеров.

• [Имя_проекта], например [Fabrikam], [FabrikamFiber], [MyProject]
• [OrganizationName], например [fabrikam], [myorganization]
• [CollectionName], например [fabrikam], [myorganization]

Чтобы узнать о область, доступных для проекта или организации, перейдите на страницу "Группы проекта Параметры> Permissions" или "Группы организации Параметры> Permissions>>", вы можете отфильтровать список по мере необходимости. Например, на следующем рисунке показаны первые четыре записи в отфильтрованный список на основе Azure DevOps. Дополнительные сведения см. в разделе "Изменение разрешений на уровне проекта" или "Изменение разрешений на уровне коллекции проектов".

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

Ниже приведены примеры маркеров.

• [Проект], например [Проект]\Участникы, [Проект]\Команда Fabrikam, [Project]\Project Утверждающий токен [Проект], указывает группу, определенную для проекта. Это может соответствовать команде, группе безопасности по умолчанию или пользовательской группе безопасности или группе Active Directory, которая была добавлена в проект.
• [GLOBAL], чтобы ссылаться на группу сбора область d, например [GLOBAL]\Project Collection Администратор istrator, используйте [GLOBAL] для ссылки на группу безопасности область коллекции, например группу Администратор istrator для коллекции или группу Windows, добавленную в коллекцию. Например:

  <FIELD name="Title">
      <READONLY for="[GLOBAL]\Project Collection Valid Users"/>
  </FIELD>
  

• [Team Foundation] Чтобы ссылаться на группу область сервера, например [Team Foundation]\Team Foundation Администратор istrator, используйте [Team Foundation] для ссылки на группу область сервера, например встроенную группу или группу Windows, добавляемую в группу уровня сервера. Например:

  <FIELD name="Title">
      <READONLY for="[Team Foundation]\Team Foundation Valid Users"/>
  </FIELD>
  

• [DomainName] для ссылки на группу с область сервера, например [Team Foundation]\Team Foundation Администратор istrators доменных имен, например имя учетной записи, показанной в следующем примере, можно использовать для ссылки на пользователя домена или группу. Некоторые правила поддерживают только группы и не поддерживают ссылки на пользователей домена.

  <LISTITEM value="FABRIKAM\Christie Church's Direct Reports"/>
  

Примечание.

[Проект], [GLOBAL] и [Team Foundation] используются как есть. Они не заменяются именем проекта, коллекции или сервера.

Чтобы узнать о область, доступных для проекта или коллекции, перейдите на страницу "Группы Параметры Project Параметры> Permissions" или "Коллекции" Параметры> "ГруппыPermissions>>". Отфильтруйте список по мере необходимости. Например, на следующем рисунке показаны первые четыре записи в отфильтрованный список на основе Azure DevOps. Дополнительные сведения см. в разделе "Изменение разрешений на уровне проекта" или "Изменение разрешений на уровне коллекции проектов".

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

<FIELD name="Title">
    <READONLY for="Dev Team"/>
</FIELD>

Дополнительные сведения о группах безопасности по умолчанию см. в разделе "Разрешения и группы"

Оценка правила

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

• При изменении рабочего элемента на веб-портале, REST API или команде azure boards выполняется запрос на идентификатор Microsoft Entra или Active Directory. Никаких проблем для этой операции не возникает.
• При изменении рабочего элемента из Visual Studio, Excel или другого пользовательского средства с помощью клиентской объектной модели WIT запрос на оценку членства основан на кэше клиента. Кэш клиента не знает о группах Active Directory.

Примечание.

Команда Обозреватель Visual Studio 2019 для проектов с помощью GIT была перезаписана для использования REST API.

Чтобы избежать проблем с пользователями, обновляемыми рабочими элементами из различных клиентов, укажите группы безопасности Azure DevOps вместо групп Active Directory. Вы можете легко создать группу безопасности Azure DevOps, чтобы соответствовать группе Active Directory. Сведения о том, как добавить или удалить пользователей или групп, управляйте группами безопасности.

Примечание.

OM клиента WIT устарел. По состоянию на 1 января 2020 г. она больше не поддерживается при работе с Azure DevOps Services и Azure DevOps Server 2020.

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

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

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

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

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

1. Из клиента Azure DevOps, например веб-портала или Visual Studio Team Обозреватель- пользователь создает новый рабочий элемент или изменяет существующий рабочий элемент.

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

3. Копирование или установка значений полей. Для всех полей примените все правила для копирования значения или задания значения поля, которое не является частью условного предложения.

4. Для всех полей с условным правилом, которое соответствует, примените правила для задания или копирования значения поля.

5. Для всех полей с соответствующим условным правилом ,примените правила для задания или копирования значения поля.

   Система всегда обрабатывает правила, предшествующие не правилам.

6. Для всех полей, которые были изменены с шага 1, и которые содержат правила при изменении , примените правила для задания или копирования значения поля.

7. Разрешить пользователю начать редактирование.

8. Пользователь изменяет значение поля, а затем перемещает фокус из поля.

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

10. Обработайте любое , если не правила для этого поля, соответствующего новому значению.

11. Обработайте любые правила при изменении для этого поля, соответствующего новому значению.

12. Возвращает возможность редактирования пользователю.

13. Пользователь сохраняет изменения в хранилище данных.

14. Для всех полей примените все Use the current time to set the value of ... действия, определенные для поля напрямую или косвенно в условном правиле.

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

Правила обычно обрабатываются в последовательности, в которой они перечислены. Однако при использовании элементов WHEN, DEFAULT и COPY могут применяться дополнительные действия. На следующих шагах показано в правильной последовательности взаимодействия, выполняемые Azure DevOps и пользователем формы рабочего элемента. Пользователь выполняет только шаги 1, 8 и 13.

1. Из клиента Azure DevOps, например веб-портала или Visual Studio Team Обозреватель- пользователь создает новый рабочий элемент или изменяет существующий рабочий элемент.

2. Заполните поля по умолчанию. Для всех полей применяются все правила DEFAULT, указанные вне или КОГДА.

3. Копирование значений полей. Для всех полей используйте все правила COPY , которые находятся вне предложений WHEN .

4. Для всех полей с правилом WHEN, которое соответствует, сначала выполните команду DEFAULT, а затем скопируйте правила внутри.

5. Для всех полей с соответствующим правилом WHENNOT сначала выполните команду DEFAULT, а затем скопируйте правила внутри.

   Система всегда обрабатывает правила WHEN до правил WHENNOT .

6. Для всех полей, которые были изменены с шага 1, и которые содержат правила WHENCHANGED, сначала сделайте значение DEFAULT, а затем скопируйте правила внутри.

7. Разрешить пользователю начать редактирование.

8. Пользователь изменяет значение поля, а затем перемещает фокус из поля.

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

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

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

12. Возвращает возможность редактирования пользователю.

13. Пользователь сохраняет изменения в базе данных.

14. Для всех полей выполните операции SERVERDEFAULT , определенные для поля напрямую или косвенно в соответствии с правилом WHEN или WHENNOT .

Записи нажатия клавиш и оценка правил

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

В следующем xml-примере система очищает MyCorp.SubStatus при вводе "Утверждено снова" в поле "Состояние", так как правило WHEN возникает, как только пользователь вводит букву "e" в "Утверждено", даже если предполагаемое окончательное значение не является "Утвердить". По этой причине тщательно думайте, когда вы используете условные правила.

<FIELD refname="MyCorp.SubStatus" />
   <WHEN field="MyCorp.Status" value="Approve" >
      <EMPTY />
   </WHEN>
</FIELD>

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

• Примеры сценариев правил
• Индекс поля рабочего элемента
• Поля и атрибуты рабочих элементов
• Изменение разрешений на уровне проекта
• Изменение разрешений на уровне коллекции проектов
• Разрешения и группы
• Унаследованный процесс
  • Добавление настраиваемого правила в тип рабочего элемента
  • Применение правил к состояниям рабочего процесса
• Локальный XML-процесс
  • Определение значения по умолчанию или копирование значения в поле
  • Определение списков выбора
  • Назначение условных значений и правил