Cenários de regra personalizada de exemplo

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

Este artigo fornece exemplos de definições de regras personalizadas. Todas as regras personalizadas são definidas para um tipo de item de trabalho. Exemplos são fornecidos para os modelos de processo XML herdados e locais.

Antes de adicionar regras personalizadas, leia Regras e avaliação de regras e Adicionar uma regra a um tipo de item de trabalho (Processo de herança).

Definir um campo obrigatório dependente

Você pode especificar que um campo é obrigatório somente quando outro campo contém um valor específico. No exemplo a seguir, quando um cliente relata um problema, o campo personalizado Relatadopelo cliente é definido como Verdadeiro e o campo Severidadese torna obrigatório. Se o problema não for relatado por um cliente, um valor para o campo Severidade não será necessário.

Processo de herança

Processo XML local

Você especifica uma WHEN instrução de regra para a definição de campo dentro da FIELDS seção da definição de tipo de item de trabalho.

<FIELDS>
   ...
   <FIELD refname="MyCorp.Severity" name="Customer Severity" type="String">  
       <ALLOWEDVALUES>  
           <LISTITEM value="Blocking" />  
           <LISTITEM value="Major" />  
           <LISTITEM value="Minor" />  
       </ALLOWEDVALUES>  
       <WHEN field="MyCorp.CustomerReported" value="true">  
           <REQUIRED />  
       </WHEN>  
   </FIELD> 
   ...
</FIELDS>     

Limpar o valor de um campo dependente

O exemplo a seguir ilustra a definição de uma regra personalizada para limpar o valor de Pontos de História quando uma alteração é feita na Data de Início.

Processo de herança

Processo XML local

Você especifica uma WHENCHANGED instrução de regra para a definição de campo dentro da FIELDS seção da definição de tipo de item de trabalho.

<FIELDS>
 ...
   <FIELD name="Story Points" refname="Microsoft.VSTS.Scheduling.StoryPoints" type="Double" reportable="measure" formula="sum">
       <HELPTEXT>The size of work estimated for implementing this user story</HELPTEXT>
       <WHENCHANGED field="Microsoft.VSTS.Scheduling.StartDate">  
           <EMPTY />  
       </WHENCHANGED>
   </FIELD>
   ...
</FIELDS>     

Definir um valor de campo dependente

Os exemplos a seguir ilustram como mapear os valores do campo Tamanho dependendo do valor selecionado para o campo personalizado, o campo Tamanho da Camiseta .

Processo de herança

A lista de escolha de tamanho da camiseta consiste em quatro valores Pequeno, Médio, Grande e X-Grande. Quatro regras personalizadas são definidas para atribuir o campo Tamanho quando o campo Tamanho da camiseta é alterado para um valor específico. Para simplificar o uso, o valor padrão do tamanho da camiseta é Pequeno.

Caixa de diálogo Editar campo para o campo Tamanho da camiseta

Regra personalizada

Quatro regras personalizadas

Processo XML local

Você especifica o valor do campo Tamanho na FIELDS seção da definição de tipo de item de trabalho. Use uma série de instruções de WHEN regra para fazer o mapeamento, definindo o valor do campo Tamanho usando a COPY value="value" regra.

<FIELDS>
   ...
   <FIELD name="Tee-Shirt Size" refname="Fabrikam.TShirt.Size" type="String">
        <HELPTEXT>Estimate of overall size for work to be done; Small (2), Medium (6), Large (18), X-Large (30).</HELPTEXT>
        <ALLOWEDVALUES expanditems="true">
          <LISTITEM value="Large" />
          <LISTITEM value="Medium" />
          <LISTITEM value="Small" />
          <LISTITEM value="X-Large" />
        </ALLOWEDVALUES>
   </FIELD> 
   <FIELD name="Size" refname="Fabrikam.Size" type="Integer">
        <HELPTEXT>Integer estimate of overall size for work to be done; Automatically fill in based on Tee-Shirt Size. Allow any value.</HELPTEXT>
        <WHEN field="Fabrikam.TShirt.Size" value="Small">
          <COPY value="2" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Medium">
          <COPY value="6" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Large">
          <COPY value="18" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="X-Large">
          <COPY value="30" />
        </WHEN>
   </FIELD>
   ...
 </FIELDS> 

Exigir um valor de campo em caso de alterações de estado

O exemplo a seguir mostra como você pode exigir a especificação do campo Trabalho Restante quando o Estado do fluxo de trabalho da tarefa for alterado para Ativo.

Processo de herança

Processo XML local

Quando o valor do campo Estado de um item de trabalho é definido como Ativo e o item de trabalho é salvo, os valores dos campos Ativado por e Atribuído a são definidos automaticamente como o nome do usuário atual. Esse usuário deve ser um membro do grupo Usuários válidos do Team Foundation Server. O valor do campo Data de Ativação também é definido automaticamente. O exemplo a seguir mostra os elementos que impõem essa regra:

<WORKFLOW>
. . .  
    <STATE value="Active">
        <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <REQUIRED />
            </FIELD>
        </FIELDS>
    </STATE>
. . .  
</WORKFLOW>

Limpar o valor de um campo ao fechar o estado

Para automatizar a limpeza do campo Trabalho Restante ao fechar uma tarefa, defina uma regra personalizada conforme indicado.

Processo de herança

Processo XML local

<WORKFLOW>
. . .  
      <STATE value="Closed">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <EMPTY />
            </FIELD>
          </FIELDS>
      </STATE>
. . .  
</WORKFLOW>

Restringir a criação de itens de trabalho por um grupo

Uma regra personalizada que restringe a transição para a categoria de estado Proposto de um tipo de item de trabalho efetivamente não permite a criação de itens de trabalho desse tipo. Ao aplicar a regra a um grupo específico, você efetivamente impede que esse grupo crie itens de trabalho desse tipo.

Processo de herança

A regra personalizada a seguir restringe uma equipe de projeto de criar itens de trabalho à medida que a categoria Estado proposto é mapeada para o estado Novo fluxo de trabalho.

Processo XML local

A regra personalizada a seguir restringe a Equipe de Revisão da Fabrikam (para atributo) de criar itens de trabalho, não permitindo a transição para o estado Novo fluxo de trabalho.

<WORKFLOW>
... 
<TRANSITION from=" " to="New"  
   for="[Project]\Developers" 
   not="[Project]\Fabrikam Review Team"  
   . . .  
</TRANSITION> 
...  
</WORKFLOW>

Restringir a modificação de itens de trabalho por um grupo

Para um processo de Herança, você pode impedir que os usuários modifiquem um item de trabalho definindo a permissão de negação para um grupo em um Caminho de Área. Para um processo XML local, você pode colocar restrições em cada estado de fluxo de trabalho para um grupo que os impede de salvar o item de trabalho em qualquer estado.

Processo de herança

Não é possível definir uma regra personalizada que restrinja a modificação de itens de trabalho de um tipo específico. Você só pode especificar restrição por estado. Se o usuário não alterar o estado, ele poderá modificar outros campos, a menos que todos os campos se tornem somente leitura para o grupo.

Em vez disso, se você quiser restringir um grupo de usuários de modificar itens de trabalho selecionados de qualquer tipo, poderá atribuir esses itens de trabalho a um Caminho de Área. Defina um grupo de segurança e, em seguida, defina restrições para editar itens de trabalho para esse Caminho de Área para esse grupo, conforme mostrado na imagem a seguir. Para saber mais, consulte Definir permissões e acesso para controle de trabalho, Criar nós filho e modificar itens de trabalho em um caminho de área

Processo XML local

A regra personalizada a seguir restringe a Equipe de Revisão da Fabrikam (para atributo) de modificar histórias de usuário, não permitindo todos os estados de fluxo de trabalho definidos para o tipo de item de trabalho de história de usuário. Como nenhum estado de fluxo de trabalho é válido para a equipe específica, os membros dessa equipe são impedidos de salvar o item de trabalho com quaisquer alterações.

<WORKFLOW>
... 
 <STATE value="New">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Active">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Resolved">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Closed">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
...  
</WORKFLOW>

Restringir transições de estado

Para processos herdados, as transições de estado de qualquer um para qualquer são definidas automaticamente. Isso permite que os usuários avancem o estado do fluxo de trabalho de novo para concluído, mas também retrocedam caso seja necessário. Ao definir regras personalizadas para restringir uma transição, lembre-se de que, se um usuário cometer um erro ao atualizar o fluxo de trabalho, talvez não consiga corrigi-lo. Por exemplo, eles poderiam atualizar o status movendo um cartão de item de trabalho para um estágio posterior no quadro Kanban, mas não movê-lo de volta.

Dica

Considere restringir uma transição de estado para alguns, mas não para todos os usuários. Dessa forma, se um usuário cometer um erro, ele poderá pedir a outro membro da equipe para redefinir o valor de Estado para ignorar a restrição.

Antes de definir regras de transição de estado, revise Regras e avaliação de regras, Regras geradas automaticamente e Como os estados de fluxo de trabalho e as categorias de estado são usados em Listas de Pendências e Quadros.

Restringir a modificação de itens de trabalho fechados

Dependendo dos seus processos de negócios, convém impedir que os usuários continuem a modificar ou atualizar itens de trabalho que foram fechados ou concluídos. Você pode adicionar regras a tipos de item de trabalho para impedir que os usuários reabram itens de trabalho fechados.

Processo de herança

Para o processo Herdados, você pode adicionar uma regra que restrinja a transição de estado. Por exemplo, a regra a seguir restringe a transição de fechado para os outros dois Estados, Novo e Ativo.

Observação

A A work item state moved from ... condição está disponível para o Azure DevOps Server 2020 e versões posteriores.

Observação

Dependendo da ação de regra especificada, o botão Salvar no formulário de item de trabalho pode estar desabilitado ou uma mensagem de erro é exibida quando um usuário restrito tenta modificar o item de trabalho.

Processo XML local

Para implantações locais, você pode adicionar regras a um tipo de item de trabalho para impedir a reabertura após o fechamento de um item de trabalho. Por exemplo, as regras de transição de fluxo de trabalho a seguir permitem que os Testadores reabram um item de trabalho, mas não os membros do grupo Desenvolvedores.

<WORKFLOW>
. . .  
<TRANSITION from="Closed" to="New"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
. . .  
</WORKFLOW>

Ocultar ou restringir a modificação de um campo com base em um usuário ou grupo

Ao selecionar o Current user is a member of group... ou Current user is not a member of group..., você pode ocultar um campo, tornar um campo somente leitura ou tornar um campo obrigatório.

Por exemplo, a condição a seguir indica que o campo Justificativa está oculto para membros que não pertencem ao grupo Fabrikam Fiber\Voice.

Observação

Os itens de trabalho estão sujeitos a regras aplicadas a eles. As regras condicionais baseadas na associação de usuários ou grupos são armazenadas em cache para o navegador da Web. Se você perceber que está restrito a atualizar um item de trabalho, talvez tenha encontrado uma dessas regras. Se você acredita que encontrou um problema que não se aplica a você, confira Problemas de cache do IndexDB de formulário de item de trabalho.

Restringir a modificação de campos selecionados com base em um usuário ou grupo

Você pode personalizar tipos de item de trabalho para restringir quem pode modificar um campo específico para um tipo de item de trabalho.

Processo de herança

Usando uma das duas condições a seguir, você pode tornar os campos de seleção obrigatórios para um usuário de um grupo de segurança ou que não seja membro de um grupo de segurança.

• current user is a member of a group...
• current user is not a member of a group...

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.

Por exemplo, você pode tornar os campos Título ou Estado Somente leitura para usuários ou grupos selecionados.

Por exemplo, o campo Prioridade , para o tipo de item de trabalho História do Usuário, torna-se somente leitura para membros do grupo Fiber\Voice da Fabrikam. Quando um usuário desse grupo abre uma História de Usuário, ele não consegue alterar o valor no campo Prioridade.

Processo XML local

Para o modelo de processo XML local, você pode personalizar tipos de item de trabalho para oferecer suporte a essas solicitações de restrição:

• Restringir quem pode criar ou modificar um item de trabalho
• Restringir quem pode criar tipos de item de trabalho específicos, como Épicos ou Recursos

Por exemplo, você pode restringir a modificação de itens de trabalho adicionando uma regra ao tipo de item de trabalho, geralmente dentro da seção FLUXO de trabalho .

Você restringe o acesso a objetos de controle de trabalho de duas maneiras:

• Defina uma regra de campo de condição, uma regra de campo baseada em condição ou uma combinação das duas que se aplique a um grupo. Você pode restringir as alterações feitas em um campo especificando uma regra de qualificação e tornando-a aplicável a um grupo específico. As regras condicionais podem incluir elementos CANNOTLOSEVALUE, EMPTY, FROZEN, NOTSAMEAS, READONLY e REQUIRED.
• Ao adicionar WITs ao grupo Categorias Ocultas, você pode impedir que a maioria dos colaboradores do projeto os crie. Você pode criar um hiperlink para um modelo que abre o formulário de item de trabalho e compartilhar esse link com os membros da equipe que você deseja criá-los.

Artigos relacionados

• Aplicar regras aos estados do fluxo de trabalho (processo de herança)
• Regras e avaliação de regras