Aplicar reglas a un campo de elemento de trabajo

Artículo
06/09/2015

Según el tipo de datos de un campo, puede establecer varias restricciones sobre los datos que se pueden introducir en ese campo. Puede establecer los valores de una lista de selección (menú desplegable), establecer los valores predeterminados, borrar entradas o restringir los cambios. Con reglas condicionales, puede aplicar reglas a un campo según las dependencias entre los diferentes valores del campo. También puede restringir quién puede modificar un campo o definir una regla para que solo se aplique a un grupo.

Todos estos elementos de regla se pueden definir en la definición de FIELD de un tipo de elemento de trabajo (WIT), sujeto a algunas restricciones de los campos del sistema. Y, excepto para HELPTEXT, puede especificar que estas reglas surtan efecto durante una transición del flujo de trabajo o como elementos secundarios dentro de un elemento FIELD (flujo de trabajo global).

Reglas de campo de elementos XML para el seguimiento de elementos de trabajo

Puede definir cualquier combinación de reglas para un campo, sujetas a las restricciones tal y como se describe en este tema.

Texto de ayuda: especifique el texto de información que aparecerá en un formulario de elemento de trabajo para un campo.

Lista de selección: especifique un menú desplegable o una lista de selección con los valores permitidos, sugeridos o prohibidos.

Reglas de valores de asignación: defina las limitaciones y el comportamiento del tiempo de ejecución:

Borrar valores, establecerlos como predeterminados, copiarlos o forzarlos para que coincidan con un modelo
Valores requeridos, de solo lectura y restringidos asignados a un campo
Restricción de quién puede crear o modificar un elemento de trabajo

Reglas condicionales: especifique cuándo un conjunto de reglas se aplicará a un campo primario.

Establecer condiciones en función del rol de usuario: aplique reglas según quién está creando o modificando el elemento de trabajo.

Usar tokens para especificar un grupo: especifique el dominio o el ámbito del grupo con el token adecuado.

¿Qué reglas se pueden aplicar a los campos de sistema?

¿Cómo puedo evitar errores de validación en campos de nombre de persona?

¿Existe alguna forma de definir una lista de selección múltiple?

¿Cuándo debo aplicar una regla de campo?

¿Cómo se evalúan las reglas? ¿Qué orden se aplica?

¿Cómo afectan a la evaluación de reglas la pulsación de teclas en un formulario?

¿Cómo puedo modificar los campos Estado y Razón?

¿Cómo hago que un campo mantenga un valor que sea la suma de otros dos valores?

¿Cuándo debo definir reglas de campo con un flujo de trabajo global?

Las reglas de campo son un componente que debe personalizar para el seguimiento de elementos de trabajo. Para obtener más información, vea Personalizar los objetos de seguimiento del trabajo para admitir los procesos de su equipo.

Para obtener información sobre cómo modificar campos o añadir reglas de campo a un archivo de definición WIT, vea Definir campos de elementos de trabajo.

Texto de ayuda

Puede personalizar el texto de ayuda o texto de información que aparece cuando un usuario apunta a un campo que aparece en un formulario de elemento de trabajo. Puede personalizar y adaptar el texto de ayuda para el mismo campo que aparece en varios WIT y varios proyectos de equipo. El texto de ayuda está restringido a 255 caracteres Unicode.

El ejemplo siguiente muestra la asignación de texto de ayuda a un campo de justificación de negocio:

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

Para ofrecer orientación a los usuarios que supere el límite de 255 caracteres, vea Proporcionar texto de ayuda, hipervínculos o contenido web en un formulario de elemento de trabajo.

Nota

La presencia de HELPTEXT se añade al tamaño de los datos almacenados y puede afectar a la escalabilidad.Si admite varios cientos de proyectos de equipo en una sola instancia TFS, sea conservador en el uso de reglas HELPTEXT.

Reglas de lista de selección

Las reglas de lista de selección definen los valores que un usuario puede o no puede seleccionar en un campo de cadena, Los valores definidos en una lista de selección aparecen en un formulario de elemento de trabajo y en el editor de consultas. Puede combinar listas, expandirlas o contraerlas. También puede utilizar los atributos for y not para aplicar o ignorar estas reglas, según quién esté modificando el elemento de trabajo.

Regla	Uso
ALLOWEDVALUES	Limita los valores que un usuario puede seleccionar según los valores especificados.
ALLOWEXISTINGVALUE	Permite que un campo conserve un valor existente, incluso si ya no está en una lista de selección. Se recomienda que incluya esta regla cuando cambie los valores de campo en una lista de selección o en listas de selección que contengan nombres de persona.
GLOBALLIST	Especifica el nombre de una lista global que contiene valores mantenidos para un proyecto de equipo o una colección de proyectos.
PROHIBITEDVALUES	Evita que los valores especificados se asignen. El elemento de trabajo no se puede guardar si el campo contiene un valor prohibido.
SUGGESTEDVALUES	Define una lista de valores entre los cuales los usuarios pueden elegir, sin estar limitados a ellos. Los usuarios pueden especificar valores que no se encuentran en esta lista.

Para tener ejemplos de cómo se usa una lista de selección, vea Definir listas de selección.

Reglas de valores de asignación

Las reglas de valores de asignación definen el comportamiento del tiempo de ejecución y las restricciones, como especificar los valores predeterminados, borrar campos, requerir campos para definirlos, etc. Puede aplicar o ignorar estas reglas según quién esté modificando el elemento de trabajo utilizando los atributos for y not.

Borrar valores, establecerlos como predeterminados, copiarlos o forzarlos para que coincidan con un modelo

Estas reglas admiten establecer como predeterminados, copiar valores de un campo a otro o forzar el valor de un campo para que coincida con un modelo establecido.

Regla	Uso
COPY	Copia un valor especificado a un campo cuando un usuario crea o modifica un elemento de trabajo.
DEFAULT	Especifica un valor para un campo que está vacío cuando un usuario crea o modifica un elemento de trabajo. Si un campo ya tiene un valor, la regla DEFAULT se ignora.
EMPTY	Borra cualquier valor que contenga el campo y lo convierte en de solo lectura cuando un usuario guarda el elemento de trabajo. No debería utilizar EMPTY con READONLY. EMPTY se utiliza principalmente durante la transición de estado para borrar campos que se aplican al estado al que el elemento se está convirtiendo.
MATCH	Fuerza las entradas hechas a un campo de cadena para que coincida con un modelo determinado de caracteres o números.
SERVERDEFAULT	Copia el nombre de usuario actual o el valor de reloj del servidor a un campo cuando un usuario guarda el elemento de trabajo. Estos campos suelen aparecer como de solo lectura en el formulario.

Para ver la estructura de sintaxis y ejemplos, vea Definir valores predeterminados o copiar valores en un campo.

Valores requeridos, de solo lectura y restringidos asignados a un campo

Estas reglas especifican restricciones a la hora de determinar o cambiar el valor de un campo.

Regla	Uso
CANNOTLOSEVALUE	Evita que los usuarios borren el campo de un valor una vez que el valor se haya especificado.
FROZEN	Evita que los usuarios cambien el valor de un campo una vez que contenga un valor. En cuanto un usuario guarda el elemento de trabajo con un valor en ese campo, el valor ya no se puede modificar.
NOTSAMEAS	Evita que a un campo se asigne el mismo valor que el que se asignó a otro campo.
READONLY	Evita que un campo se modifique en modo alguno. Tal vez desee aplicar esta regla en determinadas condiciones. Por ejemplo, después de cerrar un elemento de trabajo, desea hacer que un campo sea de solo lectura para conservar los datos con la finalidad de generar informes. No utilice READONLY con el elemento EMPTY porque EMPTY también hace que un campo sea de solo lectura. Si combina estos elementos, los resultados serán incoherentes. Además, puede hacer que un campo aparezca como de solo lectura desde el formulario del elemento de trabajo mediante el atributo ReadOnly del elemento Control. En este campo podrán escribir otros clientes, pero no a través del formulario del elemento de trabajo.
REQUIRED	Requiere que un usuario especifique un valor para el campo. Los usuarios no pueden guardar un elemento de trabajo hasta que tengan valores asignados en todos los campos requeridos.

Para ver la estructura de sintaxis, vea Referencias de todos los elementos FIELD de XML.

Restricción de quién puede crear o modificar un elemento de trabajo

Puede controlar quién puede crear o modificar un elemento de trabajo aplicando el elemento VALIDUSER a campos de nombre de persona. Cuando especifica este elemento, puede indicar qué usuario o grupo de usuarios pueden asignarse como un valor para el campo. Puede establecer que este elemento admita el atributo opcional group, que requiere que la persona que está asignada al campo debe ser un miembro directo o indirecto del grupo que especifica. De forma predeterminada, todos los miembros del grupo Usuarios válidos de Team Foundation puede especificarse en el campo.

El elemento VALIDUSER es válido solo para los tipos de campo de cadena. Puede permitir o restringir si la regla se aplica al usuario que está modificando el elemento de trabajo especificando un usuario o grupo para los atributos for o not, respectivamente.

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

Solo puede utilizar la regla VALIDUSER cuando se hace referencia a campos de nombre de persona. Los campos de sistema siguientes son ejemplos de campos de nombre de persona:

Activado por (System.ActivatedBy)
Asignado a (System.AssignedTo)
Autorizado como (System.AuthorizedAs)
Modificado por (System.ChangedBy)
Cerrado por (System.ClosedBy)
Creado por (System.CreatedBy)

Además de los campos de sistema, puede crear un campo de cadena personalizado y utilizarlo como campo de nombre de persona. También puede sincronizar campos de nombre de persona personalizados con Active Directory (especifique syncnamechanges="true").

Los campos de elemento de trabajo no distinguen entre las identidades del usuario en dominios diferentes. Por ello, “Fabrikam\ctsoapo” y “Contoso\ctsoapo” se tratan como el mismo usuario cuando se escriben en un campo que utiliza la regla VALIDUSER.

Reglas condicionales

Las reglas condicionales le permiten especificar cuándo un conjunto de reglas se aplicará a un campo primario. Puede establecer condiciones en función de si otro campo está asignado (o no asignado) a un valor determinado o de cuándo cambia (o no cambia) otro campo. Puede incluir una lista de selección y reglas de valores de asignación dentro de un elemento de regla condicional.

Regla	Uso
WHEN	Especifica las reglas que se aplicarán al campo primario cuando otro campo está asignado a un valor especificado.
WHENNOT	Especifica las reglas que se aplicarán al campo primario cuando otro campo no está asignado a un valor especificado.
WHENCHANGED	Especifica las reglas que se aplicarán al campo primario cuando cambia el valor de un campo determinado.
WHENNOTCHANGED	Especifica las reglas que se aplicarán al campo primario cuando no cambia el valor de un campo determinado.

Puede especificar varias reglas condicionales por campo. Sin embargo, solo puede especificar un único campo esencial por regla condicional. No puede anidar las reglas condicionales. Para ver la estructura de sintaxis y ejemplos, vea Asignar reglas y valores basados en condiciones.

Aplicación o ignorancia de reglas según quién está creando o modificando el elemento de trabajo

Puede hacer una regla de lista de selección o de valor de asignación que se aplique o no a un grupo de usuarios utilizando los atributos for o not. Establezca la regla para un grupo. Para tener la regla establecida para varios grupos, debe crear un grupo de TFS primario que incluya el conjunto de grupos que quiera utilizar.

Haga que un campo solo lo necesite un grupo determinado:

Utilice para para aplicar una regla a un grupo. Este ejemplo necesita que todos los usuarios del grupo de analistas junior completen el campo de segundo aprobador.
```
<FIELD name="Second Approver">
<REQUIRED for="Example1\Junior Analysts"/>
</FIELD>
```
Restrinja de la modificación de un campo a un grupo de usuarios:

Utilice no para excluir un grupo de una regla. Este ejemplo define el campo de descripción de evaluación de errores como de solo lectura para todo el mundo menos para los usuarios del grupo de comité de evaluación de errores.
```
<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>
```
Haga que unos usuarios requieran un campo y otros no:

Utilice una combinación de para y no para aplicar una regla a algunos usuarios y no aplicarla a otros. Este ejemplo define la gravedad como campo necesario para los usuarios del grupo de miembros del proyecto, pero no para los del grupo de administradores del proyecto.
```
<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>
```
Como Deny tiene prioridad sobre Allow, si un usuario está en ambos grupos, se forzaría la “no” instrucción y el campo no sería necesario.

Usar tokens para hacer referencia a grupos

Cuando restringe una regla a un grupo, debe indicar el dominio o ámbito del grupo. Para algunos valores, puede utilizar tokens.

Los campos con nombre de persona pueden aceptar valores que hagan referencia tanto a usuarios como a grupos. Los atributos de campo, para y no, se aplican a grupos. Puede utilizar los tokens siguientes al especificar valores para estos elementos.

Ámbito de un proyecto de equipo, [Project]:

El token [Project] se utiliza para especificar un grupo que está definido para un proyecto de equipo. Esto podría corresponder a un equipo, un grupo de TFS como el grupo [Proyecto]\Colaboradores, a un grupo de TFS personalizado que haya creado al nivel de proyecto o a un grupo de Windows que haya añadido a un grupo de TFS. Por ejemplo:
- Equipo: [Project]\Fabrikam Team
  
  Cuando crea un equipo, se crea un grupo de TFS que contiene los miembros asignados al equipo.
- Grupo de proyecto de equipo: [Project]\Contributors
- Grupo de Windows agregado al proyecto de equipo: [Project]\ Triage Committee
Sugerencia: puede ver una lista de grupos válidos abriendo la página de Seguridad en el contexto de administración de Team Web Access (TWA).
Ámbito de una colección de proyecto, [CollectionName]:

Use [CollectionName] para hacer referencia a un grupo de TFS del ámbito de la colección, como el grupo Project Collection Administrators o un grupo de Windows que añada a una colección. Por ejemplo:
```
<FIELD name="Title">
<READONLY for="[DefaultCollection]\Project Collection Valid Users"/>
</FIELD>
```
Ámbito de una instancia de servidor, [GLOBAL]:

Use el token [GLOBAL] para hacer referencia a un grupo de TFS del ámbito del servidor, como un grupo integrado o un grupo de Windows que añada a un grupo de nivel de servidor. Por ejemplo:
```
<FIELD name="Title">
<READONLY for="[Global]\Team Foundation Valid Users"/>
</FIELD>
```
Especifique una cuenta o grupo que cumpla los requisitos para el dominio:

El nombre de la cuenta que cumple los requisitos para el dominio, como el mostrado en el ejemplo siguiente, puede usarse para hacer referencia a un usuario o grupo de dominio. Tenga en cuenta que algunas reglas solo son compatibles con grupos y no son compatibles con usuarios de dominio de referencia.
```
<LISTITEM value="FABRIKAM\Christie Church’s Direct Reports"/>
```

Todos los usuarios y grupos deben cumplir los requisitos para uno de estos tokens. Por ejemplo, el siguiente XML no es válido porque no cumple los requisitos para el grupo especificado con un token válido.

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

Preguntas y respuestas

P: ¿Qué reglas se pueden aplicar a los campos de sistema?

R: Los campos de sistema tienen nombres de referencia System.Name, por ejemplo, System.Title y System.State. El TFS restringe la personalización de estos campos, excepto para estas instancias:

La regla HELPTEXT se puede asignar a todos los campos.
La regla READONLY se puede asignar a los campos Estado y Razón.
La mayoría de las reglas se pueden asignar a los campos de sistema Título, Asignado a, Descripción o Modificado por.

P: ¿Cómo puedo evitar errores de validación en campos de nombre de persona?

R: Para evitar errores de validación que por el contrario ocurrirían cuando los miembros dejaran el equipo y ya no estuvieran registrados como colaboradores del proyecto, incluya el elemento ALLOWEXISTINGVALUE para el campo Asignado 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 alguna forma de definir una lista de selección múltiple?

R: Esta característica no está admitida de forma nativa. Sin embargo, es posible que pueda adaptar el código fuente ofrecido en este proyecto CodePlex: Controles personalizados para el seguimiento de elementos de trabajo de TFS.

P: ¿Cómo puedo modificar los campos Estado y Razón?

R: Los campos Estado y Razón están definidos en la sección FLUJO DE TRABAJO de la definición WIT. Puede especificar que la mayoría de reglas de campo se apliquen a un campo durante un cambio de estado, selección de una razón o para una transición determinada. Para obtener más información, vea Cambiar el flujo de trabajo de un tipo de elemento de trabajo.

P: ¿Cuándo debo aplicar una regla de campo?

R: Cuando quiera que una regla se aplique a un campo en toda la vida del elemento de trabajo, especifíquelo en la definición de FIELD. Por ejemplo, un campo que es necesario para un error nuevo y activo sigue siendo necesario hasta que el error se cierre.

De lo contrario, especifique una regla que solo deba evaluarse durante un cambio de estado. Estas reglas se definen en la sección WORKFLOW de los elementos STATE, REASON o TRANSITION. Todas las reglas, excepto para HELPTEXT, pueden aplicarse en un elemento FIELD (de flujo de trabajo).

Las reglas de campo son aditivas. Esto significa que puede especificar cuatro conjuntos de reglas para el mismo campo y todas las evaluará el motor de reglas del elemento de trabajo.

Las reglas específicas de tipo de elemento de trabajo se aplicarán, independientemente de la ubicación de un elemento de trabajo, a su modelo de estado. Por ejemplo, una regla <REQUIRED /> realiza la comprobación siguiente:

"MyField Value" != NULL
Las reglas específicas de estado están establecidas para la instancia del elemento de trabajo cuando está en un estado determinado. Una regla específica de estado se fuerza cuando la condición siguiente es cierta:

State field value == "MyState" && "MyField Value" != NULL
Las reglas específicas de transición que especifique para una transición determinada están establecidas para un elemento de trabajo que se está sometiendo a una cierta transición. Estas reglas se fuerzan cuando las condiciones siguientes son ciertas:

State field value == "ToState" &&

"Previous State Before Edit/New" == "FromState"

&& "MyField Value" != NULL
Las reglas específicas de razón que especifique para una transición determinada están establecidas para una razón determinada para una transición determinada. Se procesan cuando las condiciones siguientes son ciertas:

Reason field == "MyReason" &&

State field value == "ToState" &&

"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

El ejemplo siguiente restringe la modificación del campo de severidad de cliente cuando el elemento de trabajo está en el estado activo.

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

P: ¿Cómo se evalúan las reglas?¿Qué orden se aplica?

R: Las reglas normalmente se procesan en la secuencia en la que están presentes. Sin embargo, cuando use los elementos WHEN*, DEFAULT y COPY, se pueden aplicar comportamientos adicionales.

Puede hacerse una idea de cómo se evalúan las reglas cuando aplica varias reglas a un campo. La manera en la que se evalúan las reglas no es determinante del todo. Esta sección describe el comportamiento y las interacciones que se esperan al utilizar las reglas WHEN*, DEFAULT y COPY.

Los pasos siguientes muestran, en la secuencia, correcta las interacciones que TFS realiza y que realiza otro usuario de un formulario de elemento de trabajo. El usuario solo realiza los pasos 1, 8 y 13.

El usuario crea un nuevo elemento de trabajo o edita un elemento de trabajo existente a partir de un cliente de Team Foundation, como Visual Studio, Team Explorer, Team Web Access o Team Explorer Everywhere.
Rellene los campos predeterminados. En todos los campos, use cualquier regla DEFAULT que esté fuera de las reglas WHEN*.
Copie los valores de campo. En todos los campos, use cualquier regla COPY que esté fuera de las cláusulas WHEN*.
En todos los campos con una regla WHEN que coincida, primero haga DEFAULT y después las reglas COPY dentro.
En todos los campos con una regla WHENNOT que coincida, primero haga DEFAULT y después las reglas COPY dentro.

TFS siempre procesa las reglas WHEN antes de las reglas WHENNOT.
Para todos los campos cuyos valores se han cambiado desde el paso 1 y que contengan reglas WHENCHANGED, primero haga DEFAULT y después las reglas COPY dentro.
Permita que el usuario empiece a editar.
El usuario modifica un valor de campo y después quita el foco del campo.
Genere cualquier regla WHEN para ese campo que coincida con el valor nuevo.
Genere cualquier regla WHENNOT para ese campo que coincida con el valor nuevo.
Genere cualquier regla WHENCHANGED para ese campo que coincida con el valor nuevo.
Permita que el usuario vuelva a editar.
El usuario guarda los cambios en la base de datos.
En todos los campos, realice operaciones SERVERDEFAULT que estén definidas para el campo directa o indirectamente bajo una regla WHEN o WHENNOT.

P: ¿Cómo afectan a la evaluación de reglas la pulsación de teclas en un formulario?

R: El sistema establece un nuevo valor para un campo cada vez que un usuario pulsa una tecla en un campo del formulario de elemento de trabajo de la interfaz de usuario. Esto significa que una regla condicional puede ocurrir inesperadamente siempre que se cumplan las condiciones de los requisitos previos de la regla.

En el siguiente ejemplo de XML, SubStatus se vaciará cuando escriba “Vuelto a aprobar” en el campo de estado porque la regla WHEN* ocurre cuando el usuario escribe la letra “e” en aprobado, incluso si el valor final no está “aprobado”. Por esta razón, debe ir con cuidado cuando utilice reglas condicionales.

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

P: ¿Cómo hago que un campo mantenga un valor que sea la suma de otros dos valores?

R: Esta característica no se admite de forma nativa en este momento.

P: ¿Cuándo debo definir reglas de campo con un flujo de trabajo global?

R: Use un flujo de trabajo global solo si se le ha asignado la tarea de mantener numerosos campos con las mismas definiciones y reglas en varios proyectos de equipo. El uso del flujo de trabajo global puede minimizar el trabajo necesario cuando hay que actualizar las definiciones de campo, de forma parecida a las listas globales. Para obtener más información, consulta Personalizar el flujo de trabajo global.

Compartir a través de