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

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

Condições, o item de trabalho é criado

Ações, item de trabalho é criado

Restringir uma transição com base no Estado

Condição, item de trabalho é movido

Ações, restringir uma transação com base no Estado.

Ocultar campo ou tornar o campo somente leitura ou obrigatório com base no estado e na associação de usuário ou grupo

Condição, associação ao grupo de usuários

Ações, restringir uma transação com base no Estado e na associação.

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

Condição, associação ao grupo de usuários

Ações, restringir uma transação com base no Estado e na associação.

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.

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.

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.

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 .

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.

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.

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.

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.

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.

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

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.

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.

Captura de tela da lista de grupos de permissões filtrada.

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.

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.