Aplicar uma regra a um campo do item de trabalho

Artigo
06/09/2015

Dependendo do tipo de dados de um campo, você pode definir várias restrições em dados que podem ser inseridos no 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 regras condicionais, você pode aplicar regras a um campo com base nas dependências entre os valores de campos diferentes. Também é possível restringir quem pode modificar um campo ou o escopo de uma regra para aplicar somente a um grupo.

Todos esses elementos de regra podem ser definidos dentro do FIELD definição de uma definição de WIT (tipo) de item de trabalho, sujeito a algumas restrições para campos de sistema. E, com exceção de HELPTEXT, você pode especificar essas regras sejam afetam durante uma transição de fluxo de trabalho ou como elementos filho dentro de um FIELD elemento (fluxo de trabalho Global).

Regras de campo do elemento XML de acompanhamento do item de trabalho

Você pode definir qualquer combinação de regras a um campo, sujeito às restrições, conforme descrito neste tópico.

Texto da Ajuda: especificar o texto de dica de ferramenta a ser exibido em um formulário de item de trabalho para um campo.

Lista de seleção: Especifique um menu suspenso ou escolha a lista de valores permitidos, sugeridas ou proibidos.

Atribuir valor regras: definir o comportamento do runtime e restrições:

Limpar, definir um padrão, copiar um valor ou valores para corresponder a um padrão de forçar
Exigir, somente leitura e restringir os valores atribuídos a um campo
Restringir quem pode criar ou modificar um item de trabalho

Regras condicionais: especificar quando um conjunto de regras será aplicado a um campo pai.

Definir condições com base na função de usuário: aplicar regras com base no que está criando ou modificando o item de trabalho.

Usar tokens para especificar um grupo: especifique o domínio ou escopo do grupo usando o token certo.

Quais regras podem ser aplicadas aos campos System?

Como evitar erros de validação nos campos de nome de pessoa?

Existe uma maneira de definir uma lista de opções de seleção múltipla?

Onde devo aplicar uma regra de campo?

Como as regras são avaliadas? Que ordem é aplicada?

Como entradas de pressionamento de tecla em um formulário afetam a avaliação de regra?

Como faço para modificar os campos de estado e o motivo?

Como faço para que um campo de armazenar um valor que é a soma dos outros dois campos?

Quando eu definiria regras de campo usando o fluxo de trabalho global?

Regras de campo são um componente que tiver de personalizar o controle de item de trabalho. Para saber mais, consulte Personalizar objetos de acompanhamento de trabalho para dar suporte aos processos da sua equipe.

Para obter informações sobre como modificar campos ou adicionar regras de campo para um arquivo de definição de WIT, consulte Definir campos de item de trabalho.

Texto da Ajuda

Você pode personalizar o texto de Ajuda ou texto de dica de ferramenta que aparece quando um usuário aponta para um campo que aparece em um formulário de item de trabalho. Você pode personalizar e localizar o texto de ajuda para o mesmo campo que aparece em WITs diferentes e diferentes projetos de equipe. Texto da Ajuda está restrito a 255 caracteres Unicode.

O exemplo a seguir mostra a atribuição de texto de ajuda para um campo justificativa comercial personalizado:

<FIELD name=”Business Justification” refname="Fabrikam.BusinessJustification" type="String">
<HELPTEXT>Only required when you set the Urgencyfield to Need Immediately. </HELPTEXT>
</FIELD>

Para fornecer aos usuários diretrizes que excedem o limite de 255 caracteres, consulte Fornecer texto da ajuda, hiperlinks ou conteúdo da Web em um formulário de item de trabalho.

Dica

A presença de HELPTEXT aumenta o tamanho dos dados armazenados e pode afetar a escalabilidade.Se você oferecer suporte a várias centenas de projetos de equipe em uma única instância do TFS, seja conservador no uso do HELPTEXT regras.

Escolher regras de lista

Selecionar lista regras definem os valores que um usuário pode ou não é possível escolher um campo de cadeia de caracteres. Valores definidos na lista de opções são exibidos em um formulário de item de trabalho e o editor de consulta. Você pode combinar listas e expandir ou contrair listas. Você também pode usar o for e not atributos aplicar ou ignorar essas regras, com base no que está modificando o item de trabalho.

Regra	Uso
ALLOWEDVALUES	Limites os valores que um usuário pode escolher com base nos valores especificados.
ALLOWEXISTINGVALUE	Permite que um campo reter um valor existente, mesmo que ele não tem uma lista de opções. Incluindo essa regra é recomendado quando você altera os valores de campo em uma lista de opções ou para listas de opções que contêm nomes de pessoas.
GLOBALLIST	Especifica o nome de uma lista global que contém valores mantidos para um projeto de equipe ou coleção de projetos.
PROHIBITEDVALUES	Impede que os valores especificados que está sendo atribuído. O item de trabalho não será salvo se o campo contiver um valor proibido.
SUGGESTEDVALUES	Define uma lista de valores que os usuários podem escolher, mas não estão restrito a selecionar. Os usuários podem especificar valores diferentes nessa lista.

Para exemplos de uso de listas de opções, consulte Definir listas de opções.

Atribuir regras de valor

Atribua valor regras definem o comportamento de tempo de execução e restrições, como especificar valores padrão, limpe campos, exigindo campos sejam definidos e muito mais. Você pode aplicar ou ignorar essas regras com base em quem está modificando o item de trabalho usando o for e not atributos.

Limpar, definir um padrão, copiar um valor ou valores para corresponder a um padrão de forçar

Essas regras oferecem suporte a padrões de configuração, copiando os valores de um campo para outro, ou aplicando um valor de campo para corresponder a um padrão predefinido.

Regra	Uso
COPY	Copia um valor especificado para um campo quando um usuário cria ou modifica um item de trabalho.
DEFAULT	Especifica um valor para um campo está vazio quando um usuário cria ou modifica um item de trabalho. Se um campo já tiver um valor, o DEFAULTregra será ignorada.
EMPTY	Limpa o campo de qualquer valor que ele contém e 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 os campos que se aplicam ao estado no qual o item está em transição.
MATCH	Força as entradas feitas a um campo de cadeia de caracteres de acordo com um padrão especificado de caracteres ou números.
SERVERDEFAULT	Copia o nome do usuário atual ou o valor de relógio do servidor para um campo quando um usuário salva um item de trabalho. Normalmente, esses campos aparecem como somente leitura no formulário.

Para a estrutura de sintaxe e exemplos, consulte Definir um valor padrão ou copiar um valor para um campo.

Exigir, somente leitura e restringir os valores atribuídos a um campo

Essas regras especificam restrições em especificar ou alterar o valor de um campo.

Regra	Uso
CANNOTLOSEVALUE	Impede que os usuários de limpar um campo de um valor, uma vez que um valor foi especificado.
FROZEN	Impede que os usuários alterem o valor de um campo depois que 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 ser modificado.
NOTSAMEAS	Impede que um campo que está sendo atribuído o mesmo valor que o que foi atribuído a outro campo.
READONLY	Impede que um campo seja modificado todo. Você talvez queira aplicar essa regra sob determinadas condições. Por exemplo, depois que um item de trabalho é fechado, você deseja transformar em um campo somente leitura para preservar os dados para fins de relatórios. Não use READONLY com o EMPTY elemento porque EMPTY também faz um campo somente leitura. Se você combinar esses elementos, os resultados serão inconsistentes. Além disso, você pode fazer com que um campo aparecem como somente leitura do formulário de item de trabalho com o Control elemento ReadOnly atributo. O campo pode ser gravado por outros clientes, mas não por meio do formulário de item de trabalho.
REQUIRED	Requer que um usuário especificar um valor para o campo. Os usuários não é possível salvar um item de trabalho até terem sido atribuídos valores para todos os campos obrigatórios.

Para a estrutura de sintaxe, consulte Todas as referências de elementos XML FIELD.

Restringir quem pode criar ou modificar um item de trabalho

Você pode controlar quem pode criar ou modificar um item de trabalho ao aplicar o VALIDUSER elemento para campos de nome de pessoa. Quando você especificar esse elemento, você indica qual usuário ou grupo de usuários pode ser atribuído como um valor para o campo. Você pode definir esse elemento para oferecer suporte opcional group atributo, que requer que a pessoa que é atribuída ao campo deve ser direto ou indireto membro do grupo que você especificar. Por padrão, todos os membros de usuários válidos do Team Foundation grupo pode ser especificado no campo.

O VALIDUSER elemento é válido somente para tipos de campo de cadeia de caracteres. Você pode permitir ou restringir quando a regra se aplica ao usuário que está modificando o item de trabalho especificando um usuário ou grupo para o for ou not atributos, respectivamente.

<VALIDUSER group="groupName" for="userName" not="userName" />

Você pode usar o VALIDUSER regra somente quando você se referir aos campos de nome de pessoa. Os campos de sistema a seguir são exemplos de campos de nome de pessoa:

Ativado por (System.ActivatedBy)
Atribuído a (AssignedTo)
Autorizado como (System. authorizedas)
Alterado por (changedby)
Fechado por (System.ClosedBy)
Criado por (CreatedBy)

Além dos campos de sistema, você pode criar um campo de cadeia de caracteres personalizada e usá-lo como um campo de nome de pessoa. Além disso, você pode sincronizar os campos personalizados de nome de pessoa com o Active Directory (especificar syncnamechanges="true").

Campos de item de trabalho não fazem distinção entre as identidades dos usuários em domínios diferentes. Portanto, "Fabrikam\ctsoapo" e "Contoso\ctsoapo" são tratadas como o mesmo usuário quando eles são inseridos em um campo que usa o VALIDUSER regra.

Regras condicionais

Regras condicionais permitem especificar quando um conjunto de regras será aplicado a um campo pai. Você pode definir condições com base em outro campo é atribuído (ou não atribuído) um valor especificado ou quando outro campo alterado (ou não altera). Você pode incluir a lista de opções e atribuir regras de valor dentro de um elemento de regra condicional.

Regra	Uso
WHEN	Especifica as regras para aplicar ao campo pai quando outro campo é atribuído um valor especificado.
WHENNOT	Especifica as regras para aplicar ao campo pai quando outro campo não for atribuído um valor especificado.
WHENCHANGED	Especifica as regras para aplicar ao campo pai quando valor de um campo especificado é alterado.
WHENNOTCHANGED	Especifica as regras para aplicar ao campo pai quando o valor de um campo especificado não é alterado.

Você pode especificar várias regras condicionais por campo. No entanto, você pode especificar apenas um único campo motriz por regra condicional. Você não pode aninhar regras condicionais. Para a estrutura de sintaxe e exemplos, consulte Atribuir regras e valores baseados em condicionais.

Aplicar ou ignorar as regras com base no que está criando ou modificando o item de trabalho

Você pode fazer uma escolha Listar ou atribuir valor regra para aplicar ou não se aplicam a um grupo de usuários usando o for ou not atributos. A regra a um grupo de escopo. Para que a regra de escopo a vários grupos, você deve criar um grupo do TFS pai que inclui o conjunto de grupos que você deseja usar.

Tornar um campo necessário apenas para um grupo específico:

Use para para aplicar uma regra a um grupo. Esse exemplo requer que qualquer usuário do grupo de analistas júnior para preencher o campo aprovador segundo.
```
<FIELD name="Second Approver">
<REQUIRED for="Example1\Junior Analysts"/>
</FIELD>
```
Restringir a modificação de um campo a um grupo de usuários:

Use não para excluir um grupo de uma regra. Este exemplo define o campo de descrição de triagem como somente leitura para todos, exceto os usuários no grupo comitê de triagem.
```
<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>
```
Tornar um campo necessário para alguns usuários e não para outras pessoas:

Usar uma combinação de para e não simultaneamente aplicar uma regra a alguns, mas não de outras. Este exemplo define a severidade como um campo obrigatório para os usuários do grupo de membros do projeto, mas não para os itens no grupo Administradores do projeto.
```
<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>
```
Como Deny tem precedência sobre Allow, se um usuário está em grupos, a instrução "não" deve ser impostos, tanto o campo não será necessário.

Usar tokens para grupos de referência

Quando você restringir uma regra a um grupo, você deve indicar o domínio ou o escopo do grupo. Para alguns valores, você pode usar tokens.

Campos de nome de pessoa pode aceitar valores que fazem referência a usuários e grupos. Campo atributos e não se aplicam a grupos. Você pode usar os seguintes tokens ao especificar valores para esses itens.

Escopo para um projeto de equipe – [projeto]:

O [Project] token é usado para especificar um grupo que é definido para um projeto de equipe. Isso pode corresponder a uma equipe, o grupo interno do TFS, como o grupo de \Contributors [projeto], um grupo TFS personalizado criado no nível do projeto ou um grupo do Windows que você adicionou a um grupo do TFS. Por exemplo:
- Equipe:[Project]\Fabrikam Team
  
  Quando você cria uma equipe, é criado um grupo do TFS que contém os membros atribuídos à equipe.
- Grupo de projetos de equipe:[Project]\Contributors
- Grupo do Windows adicionado a um projeto de equipe:[Project]\ Triage Committee
Dica: pode exibir uma lista de grupos válidos por abrir a página segurança no contexto de administração do Team Web Access (TWA).
Escopo para uma coleção de projetos [CollectionName]:

Use [CollectionName] para fazer referência a um grupo do TFS com escopo de conjunto, como o grupo de administradores de coleção de projeto ou um grupo do Windows que você adiciona a uma coleção. Por exemplo:
```
<FIELD name="Title">
<READONLY for="[DefaultCollection]\Project Collection Valid Users"/>
</FIELD>
```
Escopo para uma instância de servidor – [GLOBAL]:

Use o [GLOBAL] token para fazer referência a um grupo do TFS no escopo do servidor, como um grupo interno ou um grupo do Windows é adicionar a um grupo de nível de servidor. Por exemplo:
```
<FIELD name="Title">
<READONLY for="[Global]\Team Foundation Valid Users"/>
</FIELD>
```
Especifique uma conta de domínio qualificado ou grupo:

Nome da conta de domínio qualificado, como mostrado no exemplo a seguir, pode ser usado para fazer referência a um usuário de domínio ou grupo. Observe que algumas regras oferecem suporte apenas a grupos e não suporte referência usuários de domínio.
```
<LISTITEM value="FABRIKAM\Christie Church’s Direct Reports"/>
```

Todos os usuários e grupos devem ser qualificados por um desses tokens. Por exemplo, o XML a seguir não é válido porque ele não qualificar o grupo especificado com um token válido.

<FIELD name="Title">
<READONLY for="Dev Team"/>
</FIELD>

Perguntas e respostas

P: quais regras podem ser aplicadas aos campos System?

R: campos de sistema têm o sistema.Nome referência a nomes, por exemplo, Title e System.State. TFS restringe personalização desses campos, exceto para essas instâncias:

HELPTEXTregra pode ser atribuída a todos os campos.
READONLYregra pode ser atribuída aos campos de estado e o motivo.
A maioria das regras podem ser atribuídos aos campos de título, atribuído a, descrição ou alterado pelo sistema.

P: como posso evitar erros de validação nos campos de nome de pessoa?

R: para evitar erros de validação que ocorreriam quando os membros saíssem da equipe e não são registrados como colaboradores do projeto, inclua o ALLOWEXISTINGVALUE elemento 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>

P: existe uma maneira de definir uma lista de opções de seleção múltipla?

R: nativamente não há suporte para esse recurso, no entanto, você poderá adaptar o código-fonte fornecido neste projeto CodePlex: controles personalizados para acompanhamento de Item de trabalho do TFS.

P: como posso modificar os campos de estado e o motivo?

R: o estado e o motivo de campos são definidos dentro da seção de fluxo de trabalho da definição de WIT. Você pode especificar a maioria das regras de campo para aplicar a um campo durante uma alteração de estado, a 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.

P: onde devo aplicar uma regra de campo?

R: quando desejar que uma regra seja aplicada a um campo ao longo da duração do item de trabalho, especifique-o entre o FIELD definição. Por exemplo, um campo que é necessário para um bug que há de novo e ativa permanece necessário até que o bug seja fechado.

Caso contrário, especifique uma regra a ser avaliada somente durante uma alteração de estado. Essas regras são definidas dentro de WORKFLOW seção sob o STATE, REASON, ou TRANSITION elementos. Todas as regras, exceto para HELPTEXT, pode ser aplicada em uma FIELD elemento (fluxo de trabalho).

Regras de campo são aditivas. Ou seja, você pode especificar quatro conjuntos de regras para o mesmo campo que será avaliada pelo mecanismo de regra de item trabalho.

Tipo específico de item de trabalho regras se aplicam independentemente do local de um item de trabalho em seu modelo de estado. Por exemplo, um <REQUIRED /> regra executa a verificação a seguir:

"MyField Value" != NULL
Estado específico regras limitam-se a uma instância de item de trabalho quando ele estiver em um determinado estado. Uma regra específica de estado é imposta quando a seguinte condição for verdadeira:

State field value == "MyState" && "MyField Value" != NULL
Transição específico regras que você especificar para uma transição específica limitam-se a um item de trabalho que está passando por alguma 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
Motivo específico regras especificadas por um motivo específico limitam-se a um motivo específico para uma transição de particular. Eles são processados quando as seguintes condições forem 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 severidade de cliente quando o item de trabalho estiver no estado ativo.

<STATE name="Active">
   <FIELDS>
      <FIELD refname="MyCorp.Severity" >
         <READONLY />
      </FIELD>
   </FIELDS>
</STATE>

P: como as regras são avaliadas?Que ordem é aplicada?

R: normalmente, as regras são processadas na seqüência em que são listadas. No entanto, quando você usa o WHEN*, DEFAULT, e COPY elementos, comportamentos adicionais podem ser aplicadas.

Você pode ter uma idéia de como as regras são avaliadas quando várias regras se aplicam a um campo. Como as regras são avaliadas não é inteiramente determinísticas. Esta seção descreve o comportamento esperado e interações quando você estiver usando o WHEN*, DEFAULT, e COPY regras.

As etapas a seguir mostram, na sequência correta, as interações que executa TFS 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.

De client─such um Team Foundation, como o Visual Studio, Team Explorer, Team Web Access ou Team Explorer Everywhere─, um usuário cria um novo item de trabalho ou edita um item de trabalho existente.
Preencha o campo padrões. Para todos os campos, use qualquer DEFAULT regras que estão fora de WHEN* regras.
Copie os valores de campo. Para todos os campos, use qualquer COPY regras que estão fora de WHEN* cláusulas.
Para todos os campos com um WHEN regra correspondências, primeiro faça DEFAULT e COPY dentro de regras.
Para todos os campos com um WHENNOT regra correspondências, primeiro faça DEFAULT e COPY dentro de regras.

TFS sempre processa WHEN regras antes de WHENNOT regras.
Para todos os campos que tiveram seus valores alterados desde a etapa 1 e que contêm WHENCHANGED regras, primeiro faça DEFAULT e COPY dentro de regras.
Permitir que o usuário iniciar a edição.
O usuário altera o valor do campo e, em seguida, move o foco do campo.
Gerar qualquer WHEN regras que correspondem ao novo valor para esse campo.
Gerar qualquer WHENNOT regras que correspondem ao novo valor para esse campo.
Gerar qualquer WHENCHANGED regras que correspondem ao novo valor para esse campo.
Retorne a capacidade de edição para o usuário.
O usuário salva as alterações no banco de dados.
Para todos os campos, execute SERVERDEFAULT operações que são definidas para o campo seja direta ou indiretamente em uma WHEN ou um WHENNOT regra.

P: como entradas de pressionamento de tecla em um formulário afetam a avaliação de regra?

R: o sistema define um novo valor para um campo sempre que um usuário insere um pressionamento de tecla dentro de um campo por meio do formulário de item de trabalho da interface do usuário. Isso significa que uma regra condicional pode ocorrer inesperadamente sempre que condições pré-requisitos da regra forem atendidas.

No exemplo XML a seguir, será esvaziada SubStatus conforme você digita "Aprovado novamente" no campo de Status porque o WHEN* regra ocorre assim que o usuário digita a letra "e" aprovado, mesmo que o valor final desejado não for "Aprovar". Por esse motivo, pense com cuidado quando você estiver usando regras condicionais.

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

P: como faço um campo armazenar um valor que é a soma dos outros dois campos?

R: esse recurso não tem suporte nativo no momento.

P: quando definiria regras de campo usando o fluxo de trabalho global?

R: usar o fluxo de trabalho global somente quando você está atarefado manter muitos campos com as mesmas definições e regras em vários projetos de equipe. Assim como listas globais, usar o fluxo de trabalho global pode minimizar o trabalho necessário quando você precisa atualizar definições de campo. Para obter mais informações, consulte Personalizar o fluxo de trabalho global.

Share via