Regras e avaliação de regras

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

As regras são usadas para definir ou restringir atribuições de valor para um campo de item de trabalho. Há dois tipos principais de regras, regras geradas automaticamente e regras personalizadas definidas para um processo ou projeto. As regras geradas automaticamente minimizam a necessidade de adicionar regras personalizadas para áreas que devem funcionar de maneira padrão.

Você define as regras personalizadas para dar suporte aos casos de uso do seu negócio. Dependendo do tipo de dados de um campo, você pode definir várias restrições sobre quais dados podem ser inseridos nesse campo. Você pode especificar valores para uma lista de opções (menu suspenso), definir valores padrão, limpar entradas ou restringir as alterações. Com as regras condicionais, você pode aplicar regras a um campo com base nas dependências entre os valores dos diferentes campos. Também é possível restringir quem pode modificar um campo ou o escopo de uma regra para aplicar somente a um grupo.

Leia este artigo para entender o seguinte:

• Como o sistema aplica regras geradas automaticamente
• Restrições impostas à definição de regras personalizadas nos campos do sistema
• Os diferentes tipos de regras personalizadas que você pode aplicar
• Como as regras são avaliadas
• Diferença entre regras definidas para um processo de herança e um processo XML local
• Por que você deve minimizar o número de regras personalizadas definidas

Antes de definir regras personalizadas, leia Configurar e personalizar Azure Boards para obter uma ampla compreensão de como personalizar Azure Boards para atender às suas necessidades de negócios.

Dica

Minimize o número de regras definidas para um WIT. Embora você possa criar várias regras para um WIT, as regras de adição podem afetar negativamente o desempenho quando um usuário adiciona e modifica itens de trabalho. Quando os usuários salvam itens de trabalho, o sistema valida todas as regras associadas aos campos para seu tipo de item de trabalho. Sob certas condições, a expressão de validação de regras é muito complexa para ser avaliada pelo SQL.

Regras geradas automaticamente

As regras geradas automaticamente minimizam a necessidade de adicionar regras personalizadas para áreas que devem funcionar de maneira padrão.

Regras de transição do Estado

Os processos herdados geram todo o conjunto de regras de transição de estado de qualquer para qualquer dinamicamente para cada tipo de item de trabalho personalizado e estado personalizado adicionado a um fluxo de trabalho. Uma transição de qualquer estado para qualquer estado é válida.

Para processos XML locais, você deve especificar as transições válidas dentro da WORKFLOW seção da definição de tipo de item de trabalho.

Transições de estado e regras de campo por/data

Os campos Por/Data correspondem a Criado por/Data, Ativado por/Data, Resolvido por/Data e Fechado por/Data.

Para processos herdados, esses campos são definidos ou limpos automaticamente quando você faz a transição de um item de trabalho de um estado para outro. Os campos Alterado por/Data não são incluídos, pois são atualizados com cada item de trabalho salvo e não estão relacionados às transições de estado.

As regras e comportamentos padrão que regem esses campos incluem:

1. O estado Fechado está sempre contido na categoria de estado Concluído .
2. A categoria de estado Concluído não é configurável e está associada a um e apenas um Estado.
3. Este estado Fechado é sempre Fechado para processos Ágeis e CMMI, e sempre Feito para processos Scrum e Básico.
4. A geração automática dessas regras é afetada pela localidade, pois a condição da regra contém o nome do estado, que é localizado. O sistema gera regras diferentes para diferentes localidades.
5. As regras geradas automaticamente para esses campos são especificadas apenas para tipos de item de trabalho que incluem esses campos. É possível que um tipo de item de trabalho não inclua um ou mais desses campos.
6. Essas regras são necessárias quando um tipo de item de trabalho tem estados personalizados ou o tipo de item de trabalho é um tipo de item de trabalho personalizado.
7. Essas regras se aplicam apenas a processos herdados; eles nunca são gerados para os processos XML hospedado ou XML local.

Os estados de fluxo de trabalho são associados a categorias de estado para dar suporte ao fluxo de trabalho em quadros. Para obter mais informações, consulte Como os estados de fluxo de trabalho e as categorias de estado são usados em Listas de Pendências e Quadros.

Regras do campo Data de alteração de estado

Essas regras são tecnicamente muito mais simples do que as regras de Fechado por/Data de Fechamento porque não dependem de nenhum estado específico. Para qualquer tipo de item de trabalho, as mesmas regras sempre funcionarão. Eles precisam ser gerados automaticamente porque alguns tipos de item de trabalho OOB não contêm o campo Data de Alteração de Estado, portanto, quando o usuário adiciona esse campo a um tipo de item de trabalho personalizado, essas regras também precisam ser geradas automaticamente. Os mesmos princípios para as regras de Data de Fechado/Fechado também se aplicam aqui.

Regras personalizadas

Todas as regras personalizadas são opcionais. Para um processo herdado, você especifica uma regra que consiste em uma condição mais ação. Para um processo XML local, você especifica regras para um campo ou dentro do fluxo de trabalho.

Não há um mapeamento um-para-um entre os dois processos. Em alguns casos, a regra de elemento XML é definida na caixa de diálogo Editar campo para o processo herdado e não como uma regra. Outros elementos XML, como FROZEN, MATCH, NOTSAMEAS, não têm suporte no processo herdado.

Observe o seguinte:

• As regras são sempre aplicadas, não apenas quando você está interagindo com o formulário, mas também ao fazer interface por meio de outras ferramentas. Por exemplo, definir um campo como somente leitura não apenas aplica a regra no formulário de item de trabalho, mas também por meio da API e do Excel Azure DevOps Server Add-in.
• As entradas de processo herdadas especificam condições e ações para criar uma regra completa. Os elementos XML não fazem essas distinções.
• As regras de campo não dão suporte à atribuição de valores que são a soma de dois outros campos ou à execução de outros cálculos matemáticos. No entanto, você pode encontrar uma solução que atenda às suas necessidades por meio da extensão do Marketplace do Agregador TFS (Serviço Web). Consulte também Rollup de trabalho e outros campos.
• Você pode encontrar soluções adicionais para aplicar regras personalizadas a campos usando extensões do Marketplace, como a extensão de biblioteca de controle de formulário de item de trabalho.

Composição da regra

Processo de herança

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

Observação

Atualmente, apenas uma condição é suportada para regras de transição de estado. Se você estiver aplicando regras com base no Estado, consulte Aplicar regras a estados de fluxo de trabalho.

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

Condição

Ações com suporte

Definir o valor do campo ou tornar obrigatório ou somente leitura

Restringir uma transição com base no Estado

Com base na associação de um usuário ou grupo, defina o atributo de campo ou restrinja uma transição de estado

Processo XML local

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

Observação

Não há suporte para o VALIDUSER elemento para o TFS 2018 e versões posteriores.

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>

O que acontece se muitas regras forem definidas

Uma única expressão SQL é definida por projeto para validar itens de trabalho sempre que eles são criados ou atualizados. Essa expressão aumenta com o número de regras especificadas para todos os tipos de item de trabalho definidos para o projeto. Cada qualificador comportamental especificado para um campo resulta em um aumento no número de subexpressões. Regras aninhadas, regras que se aplicam somente a uma transição ou condicionadas ao valor de algum outro campo, fazem com que mais condições sejam adicionadas a uma IF instrução. Quando a expressão atinge um determinado tamanho ou complexidade, o SQL não pode mais avaliá-la e gera um erro. Remover alguns WITs ou eliminar algumas regras pode resolver o erro.

Você pode especificar valores para uma lista de opções (menu suspenso), definir valores padrão, limpar entradas ou restringir as alterações. Com as regras condicionais, você pode aplicar regras a um campo com base nas dependências entre os valores dos diferentes campos. Também é possível restringir quem pode modificar um campo ou o escopo de uma regra para aplicar somente a um grupo.

As regras de item de trabalho não existem como uma única coleção. As regras são, na verdade, geradas dinamicamente e mescladas de diferentes fontes de dados. A lógica de mesclagem é simples, consolide regras idênticas, mas não corte regras conflitantes.

Ignorar regras

Em geral, todos os itens de trabalho são validados pelo mecanismo de regras quando os usuários modificam o item de trabalho. No entanto, para dar suporte a determinados cenários, os usuários atribuídos à permissão Ignorar regras em atualizações de item de trabalho no nível do projeto podem salvar itens de trabalho sem que as regras sejam avaliadas.

As regras podem ser ignoradas de duas maneiras. A primeira é por meio dos Itens de Trabalho - atualizar a API REST e definir o bypassRules parâmetro como true. A segunda é por meio do modelo de objeto cliente, inicializando no modo bypassrules (inicialize WorkItemStore com WorkItemStoreFlags.BypassRules).

Campos do sistema e regras personalizadas

Os campos do sistema têm Sistema.Nomes de referência de nome , por exemplo , System.Title e System.State.

Os seguintes campos do sistema devem ter um valor: ID da área, Data alterada, Data de criação, Criado por, Estado e Motivo.

O mecanismo de regras restringe a configuração de condições ou ações aos campos do sistema, exceto da seguinte forma:

• Você pode tornar os campos Estado e Motivo somente leitura.
• Você pode aplicar a maioria das regras aos campos Título, Atribuído a, Descrição e Alterado por .

Se você não vir um campo listado no menu suspenso da interface do usuário da regra para o processo de herança, é por isso. Por exemplo, se você tentar tornar o Caminho da Área (System.AreaPath) somente leitura com base em uma condição, o campo Caminho da Área não estará disponível para seleção. Mesmo que você possa especificar um campo do sistema, o mecanismo de regras pode impedir que você salve a regra.

Regras padrão e de cópia

As regras padrão e de cópia modificam os valores dos campos de item de trabalho. Eles definem o comportamento e as restrições do tempo de execução, como especificar valores padrão, limpar campos, exigir que os campos sejam definidos e muito mais.

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.

Processo de herança

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

Ação de processo herdada

Descrição

Copy the value from...

Especifica outro campo que contém um valor a ser copiado para o campo atual.

Clear the value of...

Limpa o campo de qualquer valor que ele contenha.

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

Define a hora de um campo com base na configuração de hora do usuário atual.

Processo XML local

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.

Elemento XML

Uso

COPY

Copia um valor especificado para um campo quando um usuário cria ou modifica um item de trabalho.

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

DEFAULT

Especifica um valor para um campo que está vazio quando um usuário cria ou modifica um item de trabalho. Se um campo já tiver um valor, a DEFAULT regra será ignorada. As regras padrão serão executadas somente se o Is valor do campo estiver vazio no momento. Os valores com suporte incluem a hora atual (from = "clock"), o usuário atual (from = "currentuser"), um valor literal (from = "value" value = "literal") ou o valor de outro campo (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

Especifica o relógio do servidor ou o usuário atual para definir um valor de campo.

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

Regras de restrição

As regras de restrição restringem a alteração do valor de um campo. Eles definem os estados válidos para um item de trabalho. Cada restrição opera em um único campo. As restrições são avaliadas no servidor no salvamento do item de trabalho e, se alguma restrição for violada, a operação de salvamento será rejeitada.

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.

Processo de herança

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

Ação de processo herdada

Descrição

Hide the field...
Disponível apenas quando uma condição de associação de grupo é selecionada.

Especifica para não mostrar o campo no formulário de item de trabalho, essencialmente removendo a capacidade do usuário atual de alterar o valor do campo.

Make read-only

Impede que um campo seja modificado. Você pode querer aplicar essa regra sob certas condições. Por exemplo, depois que um item de trabalho é fechado, você deseja tornar um campo somente leitura para preservar os dados para fins de relatório.
Para especificar que o padrão do campo é somente leitura, especifique na caixa de diálogo Editar campo, guia Opções .

Make required

Requer que um usuário especifique um valor para o campo. Os usuários não podem salvar um item de trabalho até que tenham atribuído valores a todos os campos obrigatórios.
Para especificar o campo padrão é obrigatório, especifique na caixa de diálogo Editar campo, guia Opções .

Processo XML local

Elemento XML

Uso

ALLOWEDVALUES

Define uma lista de valores permitidos para o campo. Valores permitidos são valores que estão disponíveis para seleção em uma lista de campos em formulários de item de trabalho e no construtor de consultas. Você deve selecionar um desses valores.

CANNOTLOSEVALUE

Impede que os usuários limpem um campo de um valor depois que um valor for especificado. Esse elemento mantém o valor do campo atual e não pode ser limpo ou esvaziado.

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

FROZEN

Impede que os usuários alterem o valor de um campo depois que ele contém um valor. Assim que um usuário salva o item de trabalho com um valor nesse campo, o valor não pode mais ser modificado. Um campo congelado não pode ser alterado para nenhum valor não vazio depois que as alterações são confirmadas. No entanto, você pode limpar manualmente o campo, salvar o item de trabalho e especificar um valor diferente.

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

EMPTY

Limpa o campo de qualquer valor que ele contenha e, em seguida, torna o campo somente leitura quando um usuário salva o item de trabalho. Você não deve usar EMPTY com READONLY.
EMPTY é usado principalmente durante a transição de estado para limpar campos que se aplicam ao estado para o qual o item está em transição.

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

MATCH

Força as entradas feitas em um campo String a estarem em conformidade com um padrão especificado de caracteres ou números. Se você definir vários MATCH elementos, o valor será considerado válido se corresponder a qualquer um dos padrões especificados. Se pelo menos um elemento for bem-sucedido, o campo terá um valor válido.

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

NOTSAMEAS

Impede que um campo seja atribuído ao mesmo valor que foi atribuído a outro campo.

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

PROHIBITEDVALUES

Define uma lista de valores proibidos para o campo. Se várias ALLOWEDVALUES e/ou PROHIBITEDVALUES regras se aplicarem a um campo específico, a lista completa de valores válidos será a interseção de todas as listas de valores permitidos — ou tudo, se não houver listas de valores permitidos — menos — ou seja, definir diferença — a união de todas as listas de valores proibidos.

READONLY

Impede que um campo seja modificado. Você pode querer aplicar essa regra sob certas condições. Por exemplo, depois que um item de trabalho é fechado, você deseja tornar um campo somente leitura para preservar os dados para fins de relatório.
Não use READONLY com o EMPTY elemento porque EMPTY também torna um campo somente leitura. A combinação desses elementos pode produzir resultados inconsistentes.
Além disso, você pode fazer com que um campo apareça como somente leitura no formulário de item de trabalho usando o Control atributo element ReadOnly . O campo pode ser gravado por outros clientes, mas não por meio do formulário de item de trabalho.

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

REQUIRED

Requer que um usuário especifique um valor para o campo. Os usuários não podem salvar um item de trabalho até que tenham atribuído valores a todos os campos obrigatórios.

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

Listas de seleção

As listas de seleção definem os valores que um usuário pode ou não escolher para um campo String ou Integer. Os valores definidos em uma lista de seleção aparecem em um formulário de item de trabalho e no editor de consultas.

Processo de herança

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

Caixa de diálogo Editar campo

Descrição

Guia Definição para um campo de lista de opções

Define uma lista de valores permitidos para o campo. Valores permitidos são valores que estão disponíveis para seleção em uma lista de campos em formulários de item de trabalho e no construtor de consultas. Você deve selecionar um desses valores.

Marque a caixa de seleção Permitir que os usuários insiram seus próprios valores na guia Opções para permitir que os usuários especifiquem suas próprias entradas

Define uma lista de valores sugeridos para o campo. Os valores sugeridos são valores que estão disponíveis para seleção em uma lista de campos em formulários de item de trabalho e no construtor de consultas. Você pode inserir outros valores além dos da lista.

Processo XML local

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.

Elemento XML

Descrição

ALLOWEDVALUES

Define uma lista de valores permitidos para o campo. Valores permitidos são valores que estão disponíveis para seleção em uma lista de campos em formulários de item de trabalho e no construtor de consultas. Você deve selecionar um desses valores.

ALLOWEXISTINGVALUE

Define o campo para permitir valores existentes. Esse elemento permite que os valores de campo que já existem sejam usados, mesmo que não sejam válidos. Todos os novos valores de campo devem ser válidos.

PROHIBITEDVALUES

Define uma lista de valores proibidos para o campo.

SUGGESTEDVALUES

Define uma lista de valores sugeridos para o campo. Os valores sugeridos são valores que estão disponíveis para seleção em uma lista de campos em formulários de item de trabalho e no construtor de consultas. Você pode inserir outros valores além dos da lista.

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>

Valores ou alterações de campos condicionais

As regras condicionais especificam uma ação com base no valor de um campo igual ou não igual a um valor específico, ou se uma alteração foi ou não feita no valor de um campo específico. Em geral, as regras condicionais são aplicadas primeiro sobre as regras incondicionais. Quando várias regras condicionais são avaliadas como verdadeiras, a ordem de execução é: When, WhenNot, WhenChanged, WhenNotChanged.

Processo de herança

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

Condição hereditária

Descrição

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

Especifica uma ou mais regras a serem aplicadas ao campo atual quando outro campo tiver um valor específico.

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

Aplica uma ou mais regras ao campo atual quando o valor de um campo específico é alterado.

The value of ... (not equals) [Quando não]

Aplica uma ou mais regras ao campo atual quando outro campo não tem um valor específico.

No change was made to the value of ... [QuandoNãoAlterado]

Aplica uma ou mais regras ao campo atual quando o valor de um campo específico não é alterado.

Ação herdada

Descrição

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

Especifica a ação a ser executada em um campo específico.

Processo XML local

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.

Elemento XML

Uso

WHEN

Especifica uma ou mais regras a serem aplicadas ao campo atual quando outro campo tiver um valor específico. O elemento pai define o campo atual.
Quando o campo especificado tem o valor especificado, as regras nesse elemento são aplicadas ao campo atual.

WHENCHANGED

Especifica uma condição sob a qual aplicar uma ou mais regras ao campo atual. As regras se aplicam ao campo atual quando o valor de outro campo é alterado em uma revisão para um item de trabalho. O elemento pai define o campo atual.

WHENNOT

Especifica uma condição sob a qual aplicar uma ou mais regras ao campo atual. As regras se aplicam ao campo atual quando o valor de outro campo é alterado. O elemento pai define o campo atual.
Quando o campo especificado não contém o valor especificado, as regras nesse elemento são aplicadas ao campo atual.

WHENNOTCHANGED

Especifica uma condição sob a qual aplicar uma ou mais regras ao campo atual. As regras se aplicam ao campo atual quando o valor de outro campo não é alterado em uma revisão de um item de trabalho. O elemento pai define o campo atual.

Restrições de regra de associação de usuário ou grupo

Você pode restringir a aplicação de uma regra com base na associação do usuário atual. Recomendamos que você defina o escopo da regra para um grupo de segurança do Azure DevOps e não para um único usuário, embora você possa especificar o último. 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.

Implementação de processos

Dica

Para evitar problemas de avaliação de regra que possam surgir, especifique grupos de segurança do Azure DevOps e não grupos de segurança da ID do Microsoft Entra ou do Active Directory. Para obter mais informações, consulte Regras padrão e o mecanismo de regras.

Processo de herança

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.

Aplicável ao

Regra

Condição

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

Ação

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

Processo XML local

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.

Cenário

Uso

Tornar um campo obrigatório apenas para um grupo especificado

Use for para aplicar uma regra a um grupo. Este exemplo requer que qualquer usuário no grupo Analistas Juniores preencha o campo Segundo Aprovador.

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

Restringir a modificação de um campo a um grupo de usuários

Use not para excluir um grupo de uma regra. Este exemplo define o campo Descrição da Triagem como somente leitura para todos, exceto os usuários no grupo Comitê de Triagem.

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

Tornar um campo obrigatório para alguns usuários e não para outros

Use uma combinação de for e not para aplicar simultaneamente uma regra a alguns e não a outros. Este exemplo define Gravidade como um campo obrigatório para usuários no grupo Membros do Projeto, mas não para aqueles no grupo Administradores do Projeto. Se um usuário estiver em ambos os grupos, a instrução será imposta for e o campo será obrigatório.

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

Usar tokens para fazer referência a usuários ou grupos

Os campos de identidade ou seletor de pessoas podem aceitar valores que fazem referência a usuários e grupos. Ao restringir uma regra a um grupo, você indica o domínio ou o escopo do grupo. Para alguns valores, você pode usar tokens.

Processo de herança

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.

Processo XML local

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

Observação

[Project], [GLOBAL] e [Team Foundation] são usados como estão. Você não os substitui pelo nome do projeto, coleção ou nome do servidor.

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>

Para saber mais sobre grupos de segurança padrão, consulte Permissões e grupos

Avaliação de regra

As regras que especificam uma condição com base na associação de usuário ou grupo do usuário que modifica um item de trabalho são avaliadas de duas maneiras. Quando a regra é avaliada, o aplicativo precisa determinar se a regra se aplica ao usuário atual, verificando se esse usuário é ou não membro do grupo especificado.

• Ao modificar o item de trabalho do portal da Web, API REST ou comando azure boards , é feita uma solicitação para a ID do Microsoft Entra ou Active Directory. Não ocorrem problemas para esta operação.
• Ao modificar o item de trabalho do Visual Studio, Excel ou outra ferramenta personalizada usando o Modelo de Objeto de Cliente WIT, a solicitação para avaliar a associação é baseada em um cache de cliente. O cache do cliente não reconhece os grupos do Active Directory.

Observação

O Visual Studio 2019 Team Explorer para projetos que usam o GIT foi reescrito para usar APIs REST.

Para evitar problemas com usuários atualizando itens de trabalho de vários clientes, especifique grupos de segurança do Azure DevOps em vez de grupos do Active Directory. Você pode criar facilmente um grupo de segurança do Azure DevOps para corresponder a um grupo do Active Directory. Para saber como, consulte Adicionar ou remover usuários ou grupos, gerenciar grupos de segurança.

Observação

O OM do WIT Client foi preterido. A partir de 1º de janeiro de 2020, ele não terá mais suporte ao trabalhar em Azure DevOps Services e Azure DevOps Server 2020.

Ordem em que as regras são avaliadas

As regras são normalmente processadas na sequência em que são listadas. No entanto, a sequência completa para avaliação de todas as regras não é totalmente determinística.

Esta seção descreve o comportamento e as interações esperados quando você aplica regras condicionais, de cópia e padrão.

Processo de herança

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.

Processo XML local

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>

Artigos relacionados

• Cenários de regra de exemplo
• Índice de campos de item de trabalho
• Atributos e campos de item de trabalho
• Alterar permissões no nível do projeto
• Alterar permissões de nível de coleção do projeto
• Permissões e grupos
• Processo herdado
  • Adicionar uma regra personalizada a um tipo de item de trabalho
  • Aplicar regras a estados de fluxo de trabalho
• Processo XML local
  • Definir um valor padrão ou copiar um valor para um campo
  • Definir listas de seleção
  • Atribuir valores e regras baseados em condicionais