Avaliação de regras e regras

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

As regras são utilizadas para definir ou restringir atribuições de valores a um campo de item de trabalho. Existem 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 forma padronizada.

Pode definir regras personalizadas para suportar os seus casos de utilização empresarial. Dependendo do tipo de dados de um campo, pode definir várias restrições sobre os dados que podem ser introduzidos nesse campo. Pode especificar valores para uma lista de opções (menu pendente), definir valores predefinidos, limpar entradas ou restringir alterações. Com as regras condicionais, pode aplicar regras a um campo com base em dependências entre os valores de campos diferentes. Também pode restringir quem pode modificar um campo ou definir o âmbito de uma regra para aplicar apenas 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 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 Painéis do Azure para obter uma compreensão ampla de como personalizar os Painéis do Azure para atender às suas necessidades de negócios.

Gorjeta

Minimize o número de regras definidas para um WIT. Embora possa criar várias regras para um WIT, as regras de adição podem afetar negativamente o desempenho quando um utilizador adiciona e modifica itens de trabalho. Quando os utilizadores guardam itens de trabalho, o sistema valida todas as regras associadas aos campos do respetivo tipo de item de trabalho. Em determinadas condições, a expressão de validação de regras é demasiado complexa para o SQL avaliar.

Regras geradas automaticamente

As regras geradas automaticamente minimizam a necessidade de adicionar regras personalizadas para áreas que devem funcionar de forma padronizada.

Regras de transição de Estado

Os processos herdados geram dinamicamente todo o conjunto de regras de transição de qualquer estado para qualquer 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 Created By/Date, Activated By/Date, Resolved By/Date e Closed By/Date.

Para processos herdados, esses campos são automaticamente definidos ou limpos quando você faz a transição de um item de trabalho de um estado para outro. Os campos Por/Data alterada não são incluídos, pois são atualizados com cada item de trabalho salvo e não estão relacionados a 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 único 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 está 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. Estas 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 painéis.

Regras do campo Data de Alteração de Estado

Essas regras são tecnicamente muito mais simples do que as regras de Data Fechada Por/Data 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 de Encerramento/Data de Encerramento 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 regra. Outros elementos XML, como FROZEN, MATCH, NOTSAMEAS, não são suportados no processo herdado.

Tenha em atenção o seguinte:

• As regras são sempre aplicadas, não apenas quando você está interagindo com o formulário, mas também quando faz interface 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 de Servidor de DevOps do Azure do Excel.
• 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 suportam a atribuição de valores que são a soma de dois outros campos ou a realizaçã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 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 a outro campo. Por exemplo:

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

Nota

Atualmente, apenas uma condição é suportada para regras de transição de estado. Se estiver a aplicar 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.

Condition

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 serem afetadas durante uma transição de fluxo de trabalho ou como elementos filho dentro de um FIELD elemento (Fluxo de HELPTEXT trabalho global).

Nota

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 Razão (System.Reason) são definidos dentro da 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. Estas regras são definidas na WORKFLOW secção sob os STATEelementos , REASONou TRANSITION . Todas as regras, exceto HELPTEXT, podem ser aplicadas dentro de 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 aplicam-se 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 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 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 razão 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 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 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.

Pode especificar valores para uma lista de opções (menu pendente), definir valores predefinidos, limpar entradas ou restringir alterações. Com as regras condicionais, pode aplicar regras a um campo com base em dependências entre os valores de campos diferentes. Também pode restringir quem pode modificar um campo ou definir o âmbito de uma regra para aplicar apenas 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.

Regras de desvio

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 contornadas de duas formas. A primeira é através do Work Items - update REST API e definindo o bypassRules parâmetro como true. A segunda é através do modelo de objeto do cliente, inicializando no modo bypassrules (inicializar WorkItemStore com WorkItemStoreFlags.BypassRules).

Campos do sistema e regras personalizadas

Os campos 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 forma:

• Você pode tornar os campos Estado e Razão 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 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 em 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 do processo herdado

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

Utilização

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 suportados 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 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 do processo herdado

Descrição

Hide the field...
Disponível apenas quando uma condição de associação ao 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. Poderá querer aplicar esta 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 é necessário, especifique na caixa de diálogo Editar campo, guia Opções .

Processo XML local

Elemento XML

Utilizaçã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.

CANNOTLOSEVALUE

Impede que os usuários limpem um campo de um valor depois que um valor for especificado. Este 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 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 qualquer valor não vazio após as alterações serem confirmadas. No entanto, você pode limpar manualmente o campo, salvar o item de trabalho e, em seguida, 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 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 para 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 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 é a interseção de todas as listas de valores permitidos — ou tudo, se não houver listas de valores permitidos — menos — isto é, diferença definida — a união de todas as listas de valores proibidos.

READONLY

Impede que um campo seja modificado. Poderá querer aplicar esta 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 destes elementos pode produzir resultados inconsistentes.
Além disso, você pode fazer com que um campo apareça como somente leitura do formulário de item de trabalho usando o Control atributo element ReadOnly . O campo pode ser escrito por outros clientes, mas não através 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 opções 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 opções 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 opções são definidas através 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 adicionalmente aos da lista.

Processo XML local

Você define listas de opções usando elementos XML listados na tabela a seguir. Para obter exemplos e estrutura de sintaxe, consulte Definir listas de opções.

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 regras 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. Este 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 adicionalmente 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 estivessem 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 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 ... [QuandoAlterado]

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ãoAlterado]

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

Ação hereditária

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 seguintes elementos XML 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 suportadas para cada modelo de processo incluem as listadas na tabela a seguir.

Para obter exemplos e estrutura de sintaxe, 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

Utilização

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 neste 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 aplicam-se ao campo atual quando o valor de outro campo muda. O elemento pai define o campo atual.
Quando o campo especificado não contém o valor especificado, as regras neste 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 regras de associação de usuários ou grupos

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 possa especificar o último. Para ter a regra definida como escopo para 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

Gorjeta

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

Aplica-se a

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 a regra definida como escopo para vários grupos, você deve criar um grupo pai do Azure DevOps que inclua o conjunto de grupos que você deseja usar.

Cenário

Utilização

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 do 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 do 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 de Projeto. Se um usuário estiver em ambos os grupos, a for instrução será imposta 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 em 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, um grupo de segurança padrão ou personalizado ou um grupo do Ative Directory que foi adicionado ao projeto.
• [GLOBAL], para fazer referência a um grupo com escopo de coleção, por exemplo, [GLOBAL]\Project Collection Administrators 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 Equipa] para fazer referência a um grupo com escopo de servidor, por exemplo, [Team Foundation]\Team Foundation Administradores 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 de 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 suportam apenas grupos e não suportam a referência de utilizadores de domínio.

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

Nota

[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 Coleta>.> 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 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 regras

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 , uma solicitação para o ID do Microsoft Entra ou Ative 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 do 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 Ative Directory.

Nota

O Visual Studio 2019 Team Explorer para projetos que usam 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 Ative Directory. Você pode criar facilmente um grupo de segurança do Azure DevOps para corresponder a um grupo do Ative Directory. Para saber como, consulte Adicionar ou remover usuários ou grupos, gerenciar grupos de segurança.

Nota

O OM do cliente WIT foi preterido. A partir de 1º de janeiro de 2020, ele não terá mais suporte ao trabalhar com os Serviços de DevOps do Azure e o Azure DevOps Server 2020.

Ordem de avaliação das regras

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

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. A partir de 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 de 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. Copie ou defina 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 corresponder, aplique regras para definir ou copiar um valor de campo.

   O sistema sempre processa Quando regras antes de Quando não regras.

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 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 qualquer regra Quando Não para esse campo que corresponda 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 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. A partir de 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 de campo. Para todos os campos, aplique quaisquer regras PADRÃO especificadas fora ou regras QUANDO .

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 que corresponda, primeiro faça DEFAULT e depois COPY regras dentro.

5. Para todos os campos com uma regra WHENNOT que corresponda, primeiro faça as regras DEFAULT e depois COPY 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 as regras DEFAULT e depois COPY dentro.

7. Permitir 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. Levante quaisquer regras WHEN para esse campo que correspondam ao novo valor.

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

11. Levante quaisquer 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 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 dentro de um campo através 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 "Approved Again" no campo Status porque a regra WHEN ocorre assim que o usuário digita a letra "e" em Approved, mesmo que o valor final pretendido não seja "Approve". Por esta razão, pense cuidadosamente quando estiver a utilizar regras condicionais.

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

Artigos relacionados

• Exemplos de cenários de regras
• Índice do campo dos itens de trabalho
• Campos e atributos do item de trabalho
• Alterar permissões no nível do projeto
• Alterar permissões no nível de coleção do projeto
• Permissões e grupos
• Processo hereditário
  • Adicionar uma regra personalizada a um tipo de item de trabalho
  • Aplicar regras aos estados do fluxo de trabalho
• Processo XML local
  • Definir um valor padrão ou copiar um valor para um campo
  • Definir listas de opções
  • Atribuir valores e regras baseados em condições