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 em 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 versus 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 Quadros do Azure para obter uma compreensão ampla de como personalizar os Quadros do Azure para atender às suas necessidades comerciais.

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

Os processos herdados geram dinamicamente todo o conjunto de regras de transição de estado de qualquer para qualquer 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 na 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 Estado Concluído .
2. A categoria 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ásicos.
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 só se aplicam a processos herdados; eles nunca são gerados para os processos XML hospedado ou XML local.

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

Regras de campo Data de Alteração de Estado

Essas regras são tecnicamente muito mais simples do que as regras de Data Fechada por/Fechada porque não dependem de nenhum estado em particular. 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 Fechada 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, especifique 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 do 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 são suportados 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 interagir por meio de outras ferramentas. Por exemplo, definir um campo como somente leitura não só aplica a regra no formulário de item de trabalho, mas também por meio da API e do Suplemento do Excel Azure DevOps Server.
• 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 oferecem 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 TFS Aggregator (Web Service) Marketplace. 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 preenchidas para que a regra seja aplicada. As ações definem as operações a serem executadas. Para a maioria das regras, você pode especificar um máximo de duas condições e 10 ações por regra. Todas as regras personalizadas exigem que todas as condições sejam atendidas para serem executadas.

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

   (Condition) When a work item State isCom atividade
   (Condition) And when the value ofÁrea = de Valor do Negó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 disponíveis com as Condições selecionadas.

Condição

Ações apoiadas

Definir valor de campo ou tornar obrigatório ou somente leitura

Restringir uma transição com base no estado

Com base na associação de 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 afetem o efeito durante uma transição de fluxo de trabalho ou como elementos filho dentro de um FIELD elemento (fluxo de HELPTEXT trabalho global).

Observação

O VALIDUSER elemento não é suportado para o TFS 2018 e versões posteriores.

Onde aplicar uma regra de campo

Quando desejar 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 que é necessário para um bug que é 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, Razão ou transição, especifique-o WORKFLOW na seção .

Os campos Estado (System.State) e Reason (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 saber mais, consulte Alterar o fluxo de trabalho de um tipo de item de trabalho.

Caso contrário, especifique uma regra a ser avaliada somente durante uma alteração de estado. Essas regras são definidas na WORKFLOW seção sob os STATEelementos , REASONou TRANSITION . Todas as regras, exceto o HELPTEXT, podem 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 todos avaliados pelo mecanismo de regras.

• As regras específicas do tipo de item de trabalho se aplicam independentemente do local 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 de 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 for verdadeira:

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

• As regras específicas de transição especificadas 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 aplicadas quando as seguintes condições forem verdadeiras:

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

• As regras específicas de motivo especificadas por 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 forem 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 forem definidas demasiadas regras

Uma única expressão SQL é definida por projeto para validar itens de trabalho sempre que eles são criados ou atualizados. Essa expressão cresce 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 apenas em 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. Na verdade, as regras são geradas dinamicamente e mescladas a partir de diferentes fontes de dados. A lógica de mesclagem é simples, consolida regras idênticas, mas não corta 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 oferecer 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 do cliente, inicializando no modo bypassrules (inicializar 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 são necessários para ter um valor: ID da área, Data alterada, Data de criação, Criado por, Estado e Motivo.

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

• 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ê consiga especificar um campo do sistema, o mecanismo de regras pode restringi-lo de salvar 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 de 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 oferecem suporte à definiçã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 sã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 ao salvar o item de trabalho e, se qualquer 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 somente 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. Talvez você queira aplicar essa regra sob determinadas 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 campo padrão é 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, 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. Os 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 quando ele contém um valor. Assim que um usuário salvar o item de trabalho com um valor nesse campo, o valor não poderá 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 contém e, em seguida, torna o campo somente leitura quando um usuário salva o item de trabalho. Você não deve usar EMPTY com READONLYo .
EMPTY é usado principalmente durante a transição de estado para limpar campos que se aplicam ao estado para o qual o item está fazendo a 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 para que estejam 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 receba o 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. Talvez você queira aplicar essa regra sob determinadas 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. Os 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 adicionais aos da lista.

Processo XML local

Você define listas de seleção usando elementos XML listados na tabela a seguir. Para obter a estrutura de 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. Os 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 adicionais aos 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 campo condicional

As regras condicionais especificam uma ação com base no valor de um campo igual ou não 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 true, 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 ... [QuandoMudou]

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

The value of ... (not equals) [QuandoNã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ãoMudou]

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. Não é possível aninhar regras condicionais. As ações com suporte para cada modelo de processo incluem as listadas na tabela a seguir.

Para obter a estrutura de sintaxe e exemplos, consulte Atribuir valores e regras baseados em condicionais. 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 de 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 o escopo da regra para vários grupos, você deve criar um grupo pai de DevOps do Azure que inclua o conjunto de grupos que você deseja usar.

Implementação de processos

Dica

Para evitar problemas de avaliação de regras que possam surgir, especifique os grupos de segurança do Azure DevOps e não os grupos de segurança do Microsoft Entra ID ou do Active Directory. Para saber mais, 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 o 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 ou not no elemento rule. Você especifica o escopo da regra. Para ter o escopo da regra para vários grupos, você deve criar um grupo pai de DevOps do Azure 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 Júnior conclua 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 para 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 Severidade 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, vá para 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 de uma lista filtrada com base no Azure DevOps. Para saber mais, consulte Alterar permissões no nível do projeto ou Alterar permissões no nível da coleção do projeto.

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, a um grupo de segurança padrão ou personalizado ou a 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 com escopo de servidor, por exemplo, [Team Foundation]\Team Foundation Administrators Use [Team Foundation] para fazer referência a um grupo com escopo de servidor, como um grupo interno ou um grupo do Windows que você adiciona a um grupo de nível de servidor. Por exemplo:

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

• [DomainName] para fazer referência a um grupo com escopo de servidor, por exemplo, [Team Foundation]\Team Foundation Administrators O nome da conta qualificada para 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 oferecem suporte apenas a grupos e não oferecem 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, vá para 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 de uma lista filtrada com base no Azure DevOps. Para saber mais, consulte Alterar permissões no nível do projeto ou Alterar permissões no nível da coleção do projeto.

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, da API REST ou do comando azure boards , uma solicitação para a ID do Microsoft Entra ou o Active Directory é feita. 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 está ciente dos grupos do Active Directory.

Observação

O Visual Studio 2019 Team Explorer para projetos usando 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 cliente WIT foi preterido. A partir de 1º de janeiro de 2020, ele não tem mais suporte ao trabalhar com os Serviços de DevOps do Azure e o Servidor de DevOps do Azure 2020.

Ordem em que as regras são avaliadas

Normalmente, as regras são 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 de DevOps do Azure, 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 quaisquer padrões atribuídos ao campo que não façam parte de uma cláusula condicional.

3. Copiar ou definir valores de campo. Para todos os campos, aplique quaisquer 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 que corresponda, 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 When rules antes When Not rules.

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. Permitir que o usuário inicie a edição.

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 quaisquer regras When Not para esse campo que correspondam ao novo valor.

11. Processe quaisquer regras Quando Alterado para esse campo que correspondam ao novo valor.

12. Retornar a capacidade de edição para o usuário.

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

14. Para todos os campos, aplique quaisquer 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

Normalmente, as regras são 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 de DevOps do Azure, 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 quaisquer regras PADRÃO especificadas fora ou regras WHEN .

3. Copiar valores de campo. Para todos os campos, use quaisquer 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 rules dentro.

5. Para todos os campos com uma regra WHENNOT que corresponda, primeiro faça DEFAULT e, em seguida , COPY rules dentro.

   O sistema sempre processa regras WHEN antes de 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 rules dentro.

7. Permitir que o usuário inicie a edição.

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

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

10. Aumente quaisquer regras WHENNOT para esse campo que correspondam ao novo valor.

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

12. Retornar a capacidade de edição para o 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 sob uma regra WHEN ou WHENNOT .

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

O sistema define um novo valor para um campo sempre que um usuário insere um pressionamento de tecla dentro de 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 bem quando estiver usando 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