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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

По полям даты и времени соответствуют созданные в/день, активированные по дате, разрешены в/день и закрыты по дате.

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

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

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

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

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

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

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

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

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

Следует отметить следующее.

  • Правила всегда применяются, а не только при взаимодействии с формой, но и при взаимодействии с другими средствами. например, задание поля как доступного только для чтения применяет только правило к форме рабочего элемента, а также через API и Excel Azure DevOps Server надстройку.
  • В наследуемых записях процесса указываются условия и действия для создания полного правила. Элементы XML не делают эти различия.
  • Правила полей не поддерживают присваивание значений, которые являются суммой двух других полей или выполняют другие математические вычисления. Тем не менее вы можете найти решение, удовлетворяющее вашим потребностям с помощью расширения веб-службы "Агрегация Team Services" (Web Service) Marketplace. См. также сводный показатель работы и других полей.
  • Вы можете найти дополнительные решения для применения настраиваемых правил к полям с помощью расширений Marketplace, таких как расширение библиотеки элементов управления формы рабочего элемента.

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

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

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

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

Примечание

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

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

Condition

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

Задать значение поля или сделать обязательным или только для чтения

Условия, Рабочий элемент создан

Действия, Рабочий элемент создан

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

Условие, Рабочий элемент перемещен

Действия, ограничьте транзакцию на основе состояния.

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

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

Действия, ограничьте транзакцию на основе состояния и членства.

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

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

Действия, ограничьте транзакцию на основе состояния и членства.

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

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

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

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

Правила обхода

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

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

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

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

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

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

  • Поля состояния и причины можно сделать только для чтения.
  • Большинство правил можно применить к заголовку, Кому назначено, описанию и изменению по полям.

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

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

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

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

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

Действие унаследованного процесса

Описание

Copy the value from...

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

Clear the value of...

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

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

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

Constraint rules

Constraint rules restrict changing the value of a field. They define the valid states for a work item. Each constraint operates on a single field. Constraints are evaluated on the server on work item save, and if any constraint is violated the save operation is rejected.

You can restrict application of these rules based on the current user's group membership as described in User or group membership rule restrictions.

Most of these rule actions can be applied with the selection of any condition.

Inherited process action

Description

Hide the field...
Only available when a group membership condition is selected.

Specifies to not show the field on the work item form, essentially removing the ability for the current user to change the field's value.

Make read-only

Prevents a field from being modified at all. You might want to apply this rule under certain conditions. For example, after a work item is closed, you want to make a field read-only to preserve the data for reporting purposes.
To specify the field default is read-only, specify in Edit field dialog, Options tab.

Make required

Requires a user to specify a value for the field. Users cannot save a work item until they have assigned values to all required fields.
To specify the field default is required, specify in Edit field dialog, Options tab.

Pick lists

Pick lists define the values that a user can or can't choose for a String or Integer field. Values defined in a pick list appear on a work item form and the query editor.

For an Inherited process, pick lists are defined through the Edit field dialog.

Edit field dialog

Description

Definition tab for a picklist field

Defines a list of allowed values for the field. Allowed values are values that are available for selection in a field list on work item forms and in the query builder. You must select from one of these values.

Check the Allow users to enter their own values checkbox within the Options tab to allow users to specify their own entries

Defines a list of suggested values for the field. Suggested values are values that are available for selection in a field list on work item forms and in the query builder. You can enter other values additionally to the ones in the list.

Conditional field values or changes

Conditional rules specify an action based on the value of a field equaling or not equaling a specific value, or if a change was or wasn't made to the value of a specific field. In general, conditional rules are applied first over unconditional rules. When multiple conditional rules evaluate to true, the order of execution is: When, WhenNot, WhenChanged, WhenNotChanged.

You can specify multiple conditional rules per field. However, you can only specify a single driving field per conditional rule.

Inherited condition

Description

The value of ... (equals) [When]

Specifies one or more rules to apply to the current field when another field has a specific value.

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

Applies one or more rules to the current field when a specific field's value is changed.

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

Applies one or more rules to the current field when another field does not have a specific value.

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

Applies one or more rules to the current field when a specific field's value is not changed.


Inherited action

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 ...

Specifies the action to take on a specific field.

User or group membership rule restrictions

You can restrict application of a rule based on the current user's membership. We recommend you scope the rule to an Azure DevOps security group, and not a single user, although you can specify the latter. To have the rule scoped to multiple groups, you must create a parent Azure DevOps group that includes the set of groups that you want to use.

Process implementation

Совет

To avoid rule evaluation issues that may arise, specify Azure DevOps security groups and not Azure Active Directory or Active Directory security groups. To learn more, see Default rules and the rule engine.

As indicated in the following table, to restrict a rule based on the current user's membership, you specify one of two conditions for an Inherited process. These rules are active for Azure DevOps 2020 and later versions.

Applies to

Rule

Condition

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

Action

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

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

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

Примеры маркеров включают следующее.

  • [Имя_проекта], например [Fabrikam], [FabrikamFiber], [MyProject]
  • [Название_организации], например [Fabrikam], [myorganization]
  • [CollectionName], например [Fabrikam], [myorganization]

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

Снимок экрана списка групп разрешений FILTERED.

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

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

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

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

Примечание

Visual Studio 2019 Team Explorer для проектов, использующих GIT, были перезаписаны для использования интерфейсов api restful.

чтобы избежать проблем с пользователями, которые обновляют рабочие элементы с различных клиентов, укажите 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/теам Explorer или Team Explorer Everywhere — пользователь создает новый рабочий элемент или редактирует существующий рабочий элемент.

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

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

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

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

    Система всегда обрабатывает правила перед тем, как не правила.

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

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

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

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

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

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

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

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

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