Esta documentación está archivada y no tiene mantenimiento.

Reglas de campo disponibles

Actualización: noviembre 2007

Las reglas de campo definen el comportamiento y las restricciones en los campos. Las reglas de campo son elementos adicionales que se muestran dentro de bloques <FIELD></FIELD>. Por ejemplo, si se requiere un campo, el XML que define el campo tiene la forma siguiente:

<FIELD refname="System.Priority" name="Priority" type="String">
<HELPTTEXT>Enter the business priority of the bug</HELPTEXT>
<REQUIRED />
</FIELD>

Puede utilizar las siguientes reglas de campo para cambiar el comportamiento del mismo:

<REQUIRED />

Este campo no puede estar vacío. Puede marcar cualquier tipo de campo como necesario. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento REQUIRED (Esquema de definición de tipo de elemento de trabajo).

<READONLY />

No se puede modificar el campo. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento READONLY (Esquema de definición de tipo de elemento de trabajo).

<EMPTY />

El valor de campo se borra al confirmar y el usuario no puede especificar ningún valor. Esta regla se utiliza principalmente durante la transición de estado para borrar los campos del estado al que se realiza la transición. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento EMPTY (Esquema de definición de tipo de elemento de trabajo).

<FROZEN/>

Tan pronto como el campo tenga un valor después de una confirmación, el valor ya no se puede modificar. Sin embargo, se puede borrar el campo utilizando una restricción <EMPTY/>. El usuario puede borrar manualmente el campo, guardar el elemento de trabajo y, a continuación, especificar un valor diferente después de volverlo a cargar. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento FROZEN (Esquema de definición del tipo de elemento de trabajo).

<CANNOTLOSEVALUE/>

Después de que un campo ha adquirido un valor, no se puede borrar ni dejar vacío. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento CANNOTLOSEVALUE (Esquema de definición del tipo de elemento de trabajo).

<NOTSAMEAS field="MyCorp.Reviewer" />

El valor de campo no puede tener el mismo valor que otro campo; en este caso, el campo "MyCorp.Reviewer". El valor de campo debe ser un nombre de referencia de campo válido. Para obtener más información, vea Nombres de referencia de campos.

Ejemplos de utilización de la regla de campo NOTSAMEAS:

  • Dos campos no pueden estar vacíos al mismo tiempo.

  • El valor de campo "code reviewer" no puede ser igual al valor de campo "assigned to".

Utilice esta regla para campos del mismo tipo. No puede utilizarlo para campos de texto sin formato o HTML. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento NOTSAMEAS (Esquema de definición del tipo de elemento de trabajo).

<VALIDUSER group="group" />

El valor de campo debe ser un usuario válido que sea miembro del grupo Usuarios válidos de Team Foundation.

Esta regla admite el atributo de grupo opcional para especificar que el usuario debe ser un miembro directo o indirecto del grupo especificado. De forma predeterminada, la regla habilita a todos los usuarios que son miembros del grupo Usuarios válidos de Team Foundation. Para obtener más información, vea Utilizar símbolos (tokens) para hacer referencia a grupos y usuarios. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento VALIDUSER (Esquema de definición de tipo de elemento de trabajo).

ms194953.alert_note(es-es,VS.90).gifNota:

Si no se especifica la regla <REQUIRED/>, este campo aceptará un valor vacío. Se utiliza para tipos de campo de cadena.

ms194953.alert_note(es-es,VS.90).gifNota:

Los campos de elemento de trabajo no distinguen entre las identidades de usuario de dominios diferentes. Por consiguiente, "Example1\jaepak" y "Example2\jaepak" se tratan como el mismo usuario cuando se especifican en un campo que utiliza la regla <VALIDUSER />. Sin embargo, las identidades del usuario se distinguen por dominio en el resto de Team Foundation Server.

<ALLOWEXISTINGVALUE/>

Permite a un campo conservar un valor existente, aunque ese valor ya no esté habilitado. El comportamiento alternativo y predeterminado es forzar al usuario a modificar la hora para que coincida con los últimos valores habilitados para ese campo. Este elemento sólo tiene un efecto modificativo en los elementos del mismo bloque. Este elemento no puede aceptar los atributos for o not. Para obtener más información, vea Elemento ALLOWEXISTINGVALUE (Esquema de definición del tipo de elemento de trabajo).

<ALLOWEDVALUES/>

Lista enumerada de valores que se presenta al usuario como una lista. Los usuarios deben seleccionar uno de los valores de esta lista. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento ALLOWEDVALUES (Esquema de definición del tipo de elemento de trabajo).

<SUGGESTEDVALUES/>

Lista enumerada de valores que se presenta al usuario como una lista. Los usuarios pueden seleccionar cualquier valor. También pueden especificar un valor no incluido entre las sugerencias. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento SUGGESTEDVALUES (Esquema de definición del tipo de elemento de trabajo).

<PROHIBITEDVALUES/>

Los usuarios no pueden guardar un elemento de trabajo si el campo contiene algún valor prohibido. Los valores prohibidos se utilizan normalmente cuando un valor se permitía anteriormente pero ya no es válido. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento PROHIBITEDVALUES (Esquema de definición de tipo de elemento de trabajo).

<DEFAULT>

Cuando un usuario crea o modifica un elemento de trabajo, el elemento <DEFAULT> rellena el valor de un campo si ese campo está vacío. Si un campo ya tiene un valor, se omite la regla default. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento DEFAULT (Esquema de definición del tipo de elemento de trabajo).

ms194953.alert_note(es-es,VS.90).gifNota:

Al cambiar un elemento de trabajo, esta regla de elemento no es determinista por lo que se refiere a la selección del valor actual o anterior de otro campo.

<COPY>

Cuando un usuario crea o modifica un elemento de trabajo, el elemento <COPY> rellena el valor de un campo independientemente de que el campo ya contenga un valor. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento COPY (Esquema de definición de tipo de elemento de trabajo).

ms194953.alert_note(es-es,VS.90).gifNota:

Al cambiar un elemento de trabajo, esta regla de elemento no es determinista por lo que se refiere a la selección del valor actual o anterior de otro campo.

<SERVERDEFAULT>

A diferencia de <DEFAULT> y <COPY>, que rellenan los valores al comienzo de la edición, la regla <SERVERDEFAULT> escribe un valor cuando el elemento de trabajo se confirma en la base de datos. Esto tiene lugar en el momento de guardar y el usuario no puede reemplazar el valor. Estos campos aparecen como de sólo lectura en el formulario. Esta regla se utiliza para campos como "Modificado por última vez" y "Modificado por última vez en" para admitir registros de auditoría seguros. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento SERVERDEFAULT (Esquema de definición del tipo de elemento de trabajo).

<MATCH pattern="<pattern>"/>

Fuerza únicamente la coincidencia de modelos básicos para las cadenas. <pattern> se debería reemplazar con el modelo coincidente. Los valores válidos son "A", "N", "X". Los demás valores se toman como literales. "A" representa un carácter alfabético. "N" representa un carácter numérico. "X" representa cualquier carácter alfanumérico. Este modelo sólo se admite para los campos de tipo cadena. Este elemento acepta los atributos for y not. Para obtener más información, vea Elemento MATCH (Esquema de definición del tipo de elemento de trabajo).

Ejemplos de coincidencia de modelos

En los ejemplos siguientes se muestran las coincidencias de modelos correctas e incorrectas para una variedad de usos de campo:

Número de versión

Modelo: ANN.NN.NN

Valida

R01.03.04 o V05.08.99

Produce un error en la validación

1.3.4 o V5.8.99 o v1.3

Un identificador flexible

Modelo: XXX-XXX

Valida

001 abc o a00-b02

Produce un error en la validación

1 abc o 001.abc

Prioridad

Modelo: PN

Valida

P1 o P5 o P9

Produce un error en la validación

1 o P10

Las etiquetas de coincidencia distinguen entre mayúsculas y minúsculas, por tanto "PN" coincide con P1 y con p1.

ms194953.alert_note(es-es,VS.90).gifNota:

Puede especificar varios elementos <MATCH>. Si al menos un elemento es correcto, el campo tiene un valor válido.

Mostrar: