Regras e avaliação de regras

Para um processo herdado, cada regra consiste em duas partes: Condições e Ações. As condições definem as circunstâncias que devem ser atendidas para que a regra seja aplicada. As ações definem as operações a serem executadas. Para a maioria das regras, você pode especificar no máximo duas condições e 10 ações por regra. Todas as regras personalizadas exigem que todas as condições sejam atendidas para serem executadas.

Por exemplo, você pode tornar um campo obrigatório com base no valor atribuído ao estado e outro campo. Por exemplo:

   (Condition) When a work item State isAtivo
   (Condition) And when the value ofÁrea de = ValorNegócio
   (Action) Then make requiredPontos de história

A tabela a seguir resume as ações que estão disponíveis com as condições selecionadas.

O processo XML local define regras usando elementos XML. Todos esses elementos de regra podem ser definidos dentro da FIELD definição de uma definição de tipo de item de trabalho. E, com exceção do elemento, você pode especificar essas regras para que entrem em vigor durante uma transição de fluxo de trabalho ou como elementos filho dentro de um FIELD elemento (fluxo de HELPTEXT trabalho global).

Onde aplicar uma regra de campo

Quando você quiser que uma regra seja aplicada a um campo durante toda a vida útil do item de trabalho, especifique-a FIELD na seção. Por exemplo, um campo necessário para um bug novo e ativo permanece necessário até que o bug seja fechado. Caso contrário, se você quiser que ele seja aplicado com base em uma alteração no Estado, Motivo ou transição, especifique-o na WORKFLOW seção.

Os campos Estado (System.State) e Motivo (System.Reason) são definidos na WORKFLOW seção. Você pode especificar a maioria das regras de campo a serem aplicadas a um campo durante uma mudança de estado, seleção de um motivo ou para uma transição específica. Para obter mais informações, consulte Alterar o fluxo de trabalho para um tipo de item de trabalho.

Caso contrário, especifique uma regra a ser avaliada somente durante uma alteração no estado. Essas regras são definidas na WORKFLOW seção sob os STATEelementos , REASON, ou TRANSITION . Todas as regras, exceto , HELPTEXTpodem ser aplicadas em um FIELD elemento (Workflow).

As regras de campo são aditivas. Ou seja, você pode especificar quatro conjuntos de regras para o mesmo campo, que serão avaliados pelo mecanismo de regras.

• As regras específicas do tipo de item de trabalho se aplicam independentemente da localização de um item de trabalho em seu modelo de estado. Por exemplo, uma <REQUIRED \> regra executa a seguinte verificação:

  "MyField Value" != NULL

• As regras específicas do estado têm como escopo uma instância de item de trabalho quando ela está em um determinado estado. Uma regra específica do estado é imposta quando a seguinte condição é verdadeira:

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

• As regras específicas de transição que você especifica para uma transição específica têm como escopo um item de trabalho que está passando por uma determinada transição. Essas regras são impostas quando as seguintes condições são verdadeiras:

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

• As regras específicas do motivo que você especifica para um motivo específico têm como escopo um motivo específico para uma transição específica. Eles são processados quando as seguintes condições são verdadeiras:

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

O exemplo a seguir restringe a modificação do campo de gravidade do cliente quando o item de trabalho está no estado Ativo.

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

A maioria dessas ações de regra pode ser aplicada com a seleção de qualquer condição.

Essas regras dão suporte à configuração de padrões, à cópia de valores de um campo para outro ou à imposição de um valor de campo para corresponder a um padrão prescrito. Para obter a estrutura de sintaxe e exemplos, consulte Definir um valor padrão ou copiar um valor para um campo.

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

<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 

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

A maioria dessas ações de regra pode ser aplicada com a seleção de qualquer condição.

Para um processo herdado, as listas de seleção são definidas por meio da caixa de diálogo Editar campo.

Você define listas de seleção usando elementos XML listados na tabela a seguir. Para obter a estrutura da sintaxe e exemplos, consulte Definir listas de seleção.

Você pode combinar listas e expandir ou contratar listas. Além disso, você pode restringir a aplicação dessas regras com base na associação de grupo do usuário atual, conforme descrito em Restrições de regra de associação de usuário ou grupo.

Campos de identidade e erros de validação

Para evitar erros de validação que, de outra forma, ocorreriam quando os membros deixassem a equipe e não fossem mais registrados como colaboradores do projeto, inclua o elemento ALLOWEXISTINGVALUE para o campo Atribuído a .

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

Você pode especificar várias regras condicionais por campo. No entanto, você só pode especificar um único campo de condução por regra condicional.

Os elementos XML a seguir são usados para definir condições para quando outras regras são avaliadas. Você pode especificar várias regras condicionais por campo. No entanto, você só pode especificar um único campo de condução por regra condicional. Você não pode aninhar regras condicionais. As ações com suporte para cada modelo de processo incluem aquelas listadas na tabela a seguir.

Para obter a estrutura da sintaxe e exemplos, consulte Atribuir valores e regras baseados em condicional. Você pode restringir a aplicação dessas regras com base na associação de grupo do usuário atual, conforme descrito em Restrições de regra de associação de usuário ou grupo.

Conforme indicado na tabela a seguir, para restringir uma regra com base na associação do usuário atual, especifique uma das duas condições para um processo herdado. Essas regras estão ativas para Azure DevOps 2020 e versões posteriores.

Para restringir uma regra com base na associação do usuário atual, especifique os for atributos or not no elemento de regra. Você especifica o escopo da regra. Para ter a regra no escopo de vários grupos, você deve criar um grupo pai do Azure DevOps que inclua o conjunto de grupos que você deseja usar.

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

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

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

Exemplos de tokens incluem o seguinte:

• [ProjectName], como [Fabrikam], [FabrikamFiber], [MyProject]
• [OrganizationName], como [fabrikam], [myorganization]
• [CollectionName], como [fabrikam], [myorganization]

Para saber mais sobre os escopos disponíveis para seu projeto ou organização, acesse a página Grupos de permissões>de configurações>do projeto ou Grupos de permissões>de configurações>da organização, você pode filtrar a lista conforme necessário. Por exemplo, a imagem a seguir mostra as quatro primeiras entradas em uma lista filtrada com base no Azure DevOps. Para obter mais informações, consulte Alterar permissões no nível do projeto ou Alterar permissões no nível da coleção de projetos.

Exemplos de tokens incluem o seguinte:

• [Project], como [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approvers O token [Project] especifica um grupo definido para um projeto. Isso pode corresponder a uma equipe, um grupo de segurança padrão ou personalizado ou um grupo do Active Directory que foi adicionado ao projeto.
• [GLOBAL], para fazer referência a um grupo com escopo de coleção, por exemplo, [GLOBAL]\Administradores de Coleção de Projetos Use [GLOBAL] para fazer referência a um grupo de segurança com escopo de coleção, como o grupo Administradores de Coleção de Projetos ou um grupo do Windows adicionado a uma coleção. Por exemplo:

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

• [Fundação da Equipe] para fazer referência a um grupo no escopo do servidor, por exemplo, [Team Foundation]\Administradores do Team Foundation Use [Team Foundation] para fazer referência a um grupo no escopo do servidor, como um grupo interno ou um grupo do Windows que você adiciona a um grupo no nível do servidor. Por exemplo:

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

• [DomainName] para fazer referência a um grupo no escopo do servidor, por exemplo, [Team Foundation]\Team Foundation Administrators O nome da conta qualificada por domínio, como o mostrado no exemplo a seguir, pode ser usado para fazer referência a um usuário ou grupo de domínio. Algumas regras dão suporte apenas a grupos e não dão suporte à referência a usuários de domínio.

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

Para saber mais sobre os escopos disponíveis para seu projeto ou coleção, acesse a página Grupos de permissões>de configurações>do projeto ou Grupos de permissões>de configurações>de coleção. Filtre a lista conforme necessário. Por exemplo, a imagem a seguir mostra as quatro primeiras entradas em uma lista filtrada com base no Azure DevOps. Para obter mais informações, consulte Alterar permissões no nível do projeto ou Alterar permissões no nível da coleção de projetos.

Todos os usuários e grupos devem ser qualificados por um desses tokens. Por exemplo, o XML a seguir não é válido porque não qualifica o grupo especificado com um token válido.

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

As etapas a seguir mostram, na sequência correta, as interações que o Azure DevOps executa e pelo usuário de um formulário de item de trabalho. Somente as etapas 1, 8 e 13 são executadas pelo usuário.

1. Em um cliente do Azure DevOps, como o portal da Web ou o Visual Studio Team Explorer, um usuário cria um novo item de trabalho ou edita um item de trabalho existente.

2. Preencha os padrões do campo. Para todos os campos, aplique os padrões atribuídos ao campo que não fazem parte de uma cláusula condicional.

3. Copie ou defina valores de campo. Para todos os campos, aplique regras para copiar um valor ou definir o valor de um campo que não faça parte de uma cláusula condicional.

4. Para todos os campos com uma regra condicional When correspondente, aplique regras para definir ou copiar um valor de campo.

5. Para todos os campos com uma regra condicional Quando não corresponde, aplique regras para definir ou copiar um valor de campo.

   O sistema sempre processa as regras When antes das regras When Not .

6. Para todos os campos que tiveram seus valores alterados desde a etapa 1 e que contêm regras Quando Alterado , aplique regras para definir ou copiar um valor de campo.

7. Permita que o usuário comece a editar.

8. O usuário altera um valor de campo e, em seguida, move o foco do campo.

9. Processe quaisquer regras When para esse campo que correspondam ao novo valor.

10. Processe todas as regras When Not para esse campo que correspondam ao novo valor.

11. Processe todas as regras When Changed para esse campo que correspondam ao novo valor.

12. Devolver a capacidade de edição ao usuário.

13. O usuário salva as alterações no armazenamento de dados.

14. Para todos os campos, aplique todas as Use the current time to set the value of ... ações definidas para o campo direta ou indiretamente sob uma regra condicional.

As regras são normalmente processadas na sequência em que são listadas. No entanto, quando você usa os elementos WHEN, DEFAULT e COPY, comportamentos adicionais podem ser aplicados. As etapas a seguir mostram, na sequência correta, as interações que o Azure DevOps executa e pelo usuário de um formulário de item de trabalho. Somente as etapas 1, 8 e 13 são executadas pelo usuário.

1. Em um cliente do Azure DevOps, como o portal da Web ou o Visual Studio Team Explorer, um usuário cria um novo item de trabalho ou edita um item de trabalho existente.

2. Preencha os padrões do campo. Para todos os campos, aplique todas as regras DEFAULT especificadas fora ou QUANDO .

3. Copie os valores do campo. Para todos os campos, use todas as regras COPY que estejam fora das cláusulas WHEN .

4. Para todos os campos com uma regra WHEN correspondente, primeiro faça DEFAULT e, em seguida, COPY regras dentro.

5. Para todos os campos com uma regra WHENNOT correspondente, primeiro faça DEFAULT e depois COPY regras dentro.

   O sistema sempre processa as regras WHEN antes das regras WHENNOT .

6. Para todos os campos que tiveram seus valores alterados desde a etapa 1 e que contêm regras WHENCHANGED , primeiro faça DEFAULT e, em seguida, COPY regras dentro.

7. Permita que o usuário comece a editar.

8. O usuário altera um valor de campo e, em seguida, move o foco do campo.

9. Aumente todas as regras WHEN para esse campo que correspondam ao novo valor.

10. Levante todas as regras WHENNOT para esse campo que correspondam ao novo valor.

11. Levante todas as regras WHENCHANGED para esse campo que correspondam ao novo valor.

12. Devolver a capacidade de edição ao usuário.

13. O usuário salva as alterações no banco de dados.

14. Para todos os campos, execute operações SERVERDEFAULT definidas para o campo direta ou indiretamente em uma regra WHEN ou WHENNOT .

Entradas de pressionamento de tecla e avaliação de regras

O sistema define um novo valor para um campo sempre que um usuário insere um pressionamento de tecla em um campo por meio do formulário de item de trabalho. Isso significa que uma regra condicional pode ocorrer inesperadamente sempre que as condições de pré-requisito da regra forem atendidas.

No exemplo XML a seguir, o sistema esvazia MyCorp.SubStatus quando você digita "Aprovado novamente" no campo Status porque a regra WHEN ocorre assim que o usuário digita a letra "e" em Aprovado, mesmo que o valor final pretendido não seja "Aprovar". Por esse motivo, pense cuidadosamente ao usar regras condicionais.

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