Exemplos de cenários de regras personalizadas

Serviços de DevOps do Azure | 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. São fornecidos exemplos para os modelos de processo XML Herdados e No Local.

Antes de adicionar regras personalizadas, leia Avaliação de regras e 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 Relatado pelo Cliente é definido como Verdadeiro e o campo Severidadese torna necessá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 instrução de WHEN 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 instrução de WHENCHANGED 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, campo Tamanho da camisa.

Processo de herança

A lista de opções do 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. Você usa 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 muda 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 automaticamente definidos 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 a 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 de 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, impedindo 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 a 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 do 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 a restrição por estado. Se o usuário não alterar o estado, ele poderá modificar outros campos, a menos que todos os campos sejam tornados 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, você pode 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 acompanhamento 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 o atributo) de modificar histórias de usuário, despermitindo todos os estados de fluxo de trabalho definidos para o tipo de item de trabalho da história do 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 qualquer estado para qualquer estado 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 podem 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.

Gorjeta

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 pode pedir a outro membro da equipe para redefinir o valor State para contornar 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 e categorias de estado do fluxo de trabalho são usados em Listas de pendências e painéis.

Restringir a modificação de itens de trabalho fechados

Dependendo de 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 aos tipos de item de trabalho para impedir que os usuários reabram itens de trabalho fechados.

Processo de herança

Para o processo herdado, 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.

Nota

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

Nota

Dependendo da ação de regra especificada, o botão Salvar no formulário de item de trabalho pode ser 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 evitar a reabertura após o fechamento de um item de trabalho. Por exemplo, as seguintes regras de transição de fluxo de trabalho permitem que os testadores reabram um item de trabalho, mas não 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 num utilizador 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 Justificação está oculto para membros que não pertencem ao grupo Fiber\Voice da Fabrikam.

Nota

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

Restringir a modificação de campos selecionados com base num utilizador 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 selecionar campos 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...

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.

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 User Story, 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 dar 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 na seção FLUXO de TRABALHO .

Você restringe o acesso a objetos de rastreamento 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 aplica 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)
• Avaliação de regras e regras