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 Relatório do Cliente é definido como Verdadeiro e o campo Gravidade se torna obrigatório. Se o problema não for relatado por um cliente, um valor para o campo Gravidade não será necessário.
Limpar o valor de um campo dependente
O exemplo a seguir ilustra a definição de uma regra personalizada para limpar o valor de Story Points quando uma alteração é feita na Data de início.
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 camiseta.
A lista de opções Tamanho da camiseta consiste em quatro valores : Pequeno, Médio, Grande e Extragrande. 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
Exigir um valor de campo após 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.
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.
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 não permite que esse grupo crie itens de trabalho desse tipo.
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.
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.
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 somente leitura para o grupo.
Em vez disso, se você quiser impedir que um grupo de usuários modifique 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 obter mais informações, consulte Definir permissões e acesso para acompanhamento de trabalho, Criar nós filho e modificar itens de trabalho em um caminho de área
Restringir transições de estado
Para processos herdados, as transições de estado de qualquer 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 podem atualizar o status movendo um cartão de item de trabalho para um estágio posterior no quadro, 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 do Estado para ignorar a restrição.
Antes de definir regras de transição de estado, examine 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 de seus processos de negócios, talvez você queira 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.
Para o processo Inherited, você pode adicionar uma regra que restringe 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 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 ser desabilitado ou uma mensagem de erro é exibida quando um usuário restrito tenta modificar o item de trabalho.
Ocultar ou restringir a modificação de um campo com base em um usuário ou grupo
Ao selecionar ou Current user is a member of group... Current user is not a member of group..., você pode ocultar um campo, torná-lo somente leitura ou torná-lo 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 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 os tipos de item de trabalho para restringir quem pode modificar um campo específico para um tipo de item de trabalho.
Observação
Para Azure DevOps Server 2019 e versões anteriores, você só pode restringir a modificação de itens de trabalho com base em um usuário ou grupo com o modelo de processo XML local.
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 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.
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 Fabrikam Fiber\Voice. Quando um usuário desse grupo abre uma História de usuário, ele não pode alterar o valor no campo Prioridade.
