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

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

  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-элементы не делают эти различия.
  • Правила полей не поддерживают назначение значений, которые являются суммой двух других полей или выполнением других математических вычислений. Тем не менее, вы можете найти решение, которое соответствует вашим потребностям с помощью расширения Marketplace Aggregator (веб-службы) TFS . Дополнительные сведения см. в разделе "Свертка работы" и других полей.
  • Вы можете найти дополнительные решения для применения настраиваемых правил к полям с помощью расширений Marketplace, таких как расширение библиотеки элементов управления формой рабочего элемента.

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

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

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

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

Примечание

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

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

Condition

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

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

Conditions, work item is created

Actions, work item is created

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

Condition, work item is moved

Actions, restrict a transaction based on State.

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

Condition, user group membership

Actions, restrict a transaction based on State and membership.

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

Condition, user group membership

Actions, restrict a transaction based on State and membership.

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

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

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

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

Обход правил

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание

Copy the value from...

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

Clear the value of...

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

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

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

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

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

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

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

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

Описание

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

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

Make read-only

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

Make required

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

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

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

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

Диалоговое окно "Изменение поля"

Описание

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

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

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

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

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

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

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

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

Описание

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]

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


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

Описание

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

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

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

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

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

Совет

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

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

Относится к

Правило

Условие

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

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

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

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

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

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

Screenshot of filtered Permissions groups list.

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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