Reglas y evaluación de reglas

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Las reglas se usan para establecer o restringir las asignaciones de valores a un campo de elemento de trabajo. Hay dos tipos principales de reglas, las generadas automáticamente y las personalizadas definidas para un proceso o proyecto. Las reglas generadas automáticamente minimizan la necesidad de agregar reglas personalizadas para áreas que deberían funcionar de forma estándar.

Las reglas personalizadas se definen para admitir los casos de uso empresariales. 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.

Lea este artículo para comprender lo siguiente:

• Cómo aplica el sistema las reglas generadas automáticamente
• Restricciones colocadas en la definición de reglas personalizadas en campos del sistema
• Los distintos tipos de reglas personalizadas que puede aplicar
• Cómo se evalúan las reglas
• Diferencia entre las reglas definidas para un proceso de herencia frente a un proceso XML local
• Por qué debe minimizar el número de reglas personalizadas que defina

Antes de definir reglas personalizadas, lea Configuración y personalización de Azure Boards para comprender ampliamente cómo personalizar Azure Boards para satisfacer sus necesidades empresariales.

Sugerencia

Minimice el número de reglas que defina para un WIT. Aunque puede crear varias reglas para un WIT, las reglas de adición pueden afectar negativamente al rendimiento cuando un usuario agrega y modifica elementos de trabajo. Cuando los usuarios guardan elementos de trabajo, el sistema valida todas las reglas asociadas a los campos para su tipo de elemento de trabajo. En determinadas condiciones, la expresión de validación de la regla es demasiado compleja para que SQL la evalúe.

Reglas generadas automáticamente

Las reglas generadas automáticamente minimizan la necesidad de agregar reglas personalizadas para áreas que deberían funcionar de forma estándar.

Reglas de transición de estado

Los procesos heredados generan todo el conjunto de reglas de transición de estado a cualquier de forma dinámica para cada tipo de elemento de trabajo personalizado y el estado personalizado agregado a un flujo de trabajo. Una transición de cualquier estado a cualquier estado es válida.

Para los procesos XML locales, debe especificar las transiciones válidas dentro de la sección de la WORKFLOW definición de tipo de elemento de trabajo.

Transiciones de estado y reglas de campo Por/Fecha

Los campos By/Date corresponden a Created By/Date, Activated By/Date, Resolved By/Date y Closed By/Date.

En el caso de los procesos heredados, estos campos se establecen o borran automáticamente al realizar la transición de un elemento de trabajo de un estado a otro. Los campos Modificados por fecha no se incluyen ya que se actualizan con cada elemento de trabajo guardado y no están relacionados con las transiciones de estado.

Las reglas y comportamientos predeterminados que rigen estos campos incluyen:

1. El estado Closed siempre está incluido en la categoría Estado completado .
2. La categoría Estado completado no es configurable y está asociada a uno y solo un estado.
3. Este estado Cerrado siempre está cerrado para los procesos agile y CMMI, y siempre listo para los procesos de Scrum y Basic.
4. La generación automática de estas reglas se ve afectada por la configuración regional, ya que la condición de regla contiene el nombre de estado, que se localiza. El sistema genera diferentes reglas para diferentes configuraciones regionales.
5. Las reglas generadas automáticamente para estos campos solo se especifican para los tipos de elementos de trabajo que incluyen estos campos. Es posible que un tipo de elemento de trabajo no incluya uno o varios de estos campos.
6. Estas reglas son necesarias cuando un tipo de elemento de trabajo tiene estados personalizados o el tipo de elemento de trabajo es un tipo de elemento de trabajo personalizado.
7. Estas reglas solo se aplican a los procesos heredados; nunca se generan para los procesos XML hospedados o XML locales.

Los estados de flujo de trabajo están asociados a categorías de estado para admitir el flujo de trabajo en paneles Kanban. Para obtener más información, consulte Cómo se usan los estados de flujo de trabajo y las categorías de estado en Trabajos pendientes y paneles.

Reglas de campo De fecha de cambio de estado

Estas reglas son técnicamente mucho más sencillas que las reglas cerradas por fecha cerrada porque no dependen de ningún estado determinado. Para cualquier tipo de elemento de trabajo, las mismas reglas siempre funcionarán. Deben generarse automáticamente porque algunos tipos de elementos de trabajo OOB no contienen el campo Fecha de cambio de estado, por lo que cuando el usuario agrega este campo a un tipo de elemento de trabajo personalizado, estas reglas también deben generarse automáticamente. Los mismos principios para las reglas Closed By/Closed Date también se aplican aquí.

Reglas personalizadas

Todas las reglas personalizadas son opcionales. Para un proceso heredado, especifique una regla que consta de una condición más una acción. Para un proceso XML local, especifique reglas para un campo o dentro del flujo de trabajo.

No hay una asignación uno a uno entre los dos procesos. En algunos casos, la regla de elementos XML se define dentro del cuadro de diálogo Editar campo para el proceso heredado y no como regla. Otros elementos XML, como FROZEN, MATCH, NOTSAMEAS, , no se admiten en el proceso heredado.

Tenga en cuenta lo siguiente:

• Las reglas siempre se aplican, no solo cuando interactúa con el formulario, sino también al interactuar con otras herramientas. Por ejemplo, establecer un campo como de solo lectura no solo aplica la regla en el formulario de elemento de trabajo, sino también a través de la API y el complemento de Azure DevOps Server de Excel.
• Las entradas de proceso heredadas especifican condiciones y acciones para realizar una regla completa. Los elementos XML no distinguen esas diferencias.
• Las reglas de campo no admiten la asignación de valores que son la suma de otros dos campos o que realizan cálculos matemáticos. Sin embargo, puede encontrar una solución que se adapte a sus necesidades a través de la extensión de Marketplace del agregador de TFS (servicio web). Consulte también Acumulación de trabajo y otros campos.
• Puede encontrar soluciones adicionales para aplicar reglas personalizadas a campos mediante extensiones de Marketplace, como la extensión biblioteca de control de formularios del elemento de trabajo.

Composición de reglas

Proceso de herencia

Para un proceso heredado, cada regla consta de dos partes: Condiciones y acciones. Las condiciones definen las circunstancias que deben cumplirse para que se aplique la regla. Las acciones definen las operaciones que se van a realizar. Para la mayoría de las reglas, puede especificar un máximo de dos condiciones y 10 acciones por regla. Todas las reglas personalizadas requieren que se cumplan todas las condiciones para poder ejecutarse.

Por ejemplo, puede hacer que un campo sea necesario en función del valor asignado al estado y a otro campo. Por ejemplo:

   (Condition) When a work item State isActivo
   (Condition) And when the value ofValue Area = Business
   (Action) Then make requiredPuntos de historia

Nota:

Actualmente, solo se admite una condición para las reglas de transición de estado. Si aplica reglas basadas en el estado, consulte Aplicar reglas a estados de flujo de trabajo.

En la tabla siguiente se resumen las acciones que están disponibles con las condiciones seleccionadas.

Condition

Acciones admitidas

Establecer el valor de campo o hacer necesario o de solo lectura

Restricción de una transición basada en el estado

Según y la pertenencia a grupos o usuarios, establezca el atributo de campo o restrinja una transición de estado.

Proceso XML local

El proceso XML local define reglas mediante elementos XML. Todos estos elementos de regla se pueden definir dentro de la FIELD definición de una definición de tipo de elemento de trabajo. Además, con la excepción del HELPTEXT elemento, puede especificar estas reglas para que afecten durante una transición de flujo de trabajo o como elementos secundarios dentro de un FIELD elemento (flujo de trabajo global).

Nota:

El VALIDUSER elemento no es compatible con TFS 2018 y versiones posteriores.

Dónde aplicar una regla de campo

Cuando desee que una regla se aplique a un campo durante toda la vida del elemento de trabajo, especifíquela dentro de la FIELD sección. Por ejemplo, un campo necesario para un error nuevo y activo permanece necesario hasta que se cierre el error. De lo contrario, si quiere que se aplique en función de un cambio en Estado, Motivo o transición, especifíquelo dentro de la WORKFLOW sección.

Los campos State (System.State) y Reason (System.Reason) se definen en la WORKFLOW sección . Puede especificar la mayoría de las reglas de campo que se aplicarán a un campo durante un cambio de estado, la selección de un motivo o una transición específica. Para más información, consulte Cambio del flujo de trabajo para un tipo de elemento de trabajo.

De lo contrario, especifique una regla que se va a evaluar solo durante un cambio en estado. Estas reglas se definen dentro de la WORKFLOW sección de los STATEelementos , REASONo TRANSITION . Todas las reglas, excepto para HELPTEXT, se pueden aplicar dentro de un FIELD elemento (Flujo de trabajo).

Las reglas de campo son sumadas. Es decir, puede especificar cuatro conjuntos de reglas para el mismo campo que evaluará todo el motor de reglas.

• Las reglas específicas del tipo de elemento de trabajo se aplican independientemente de la ubicación de un elemento de trabajo en su modelo de estado. Por ejemplo, una <REQUIRED \> regla realiza la comprobación siguiente:

  "MyField Value" != NULL

• Las reglas específicas del estado se limitan a una instancia de elemento de trabajo cuando se encuentra en un estado determinado. Se aplica una regla específica de estado cuando se cumple la siguiente condición:

  State field value == "MyState" && "MyField Value" != NULL

• Las reglas específicas de transición que especifique para una transición específica se limitan a un elemento de trabajo que está realizando una transición determinada. Estas reglas se aplican cuando se cumplen las condiciones siguientes:

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

• Las reglas específicas del motivo que especifique para un motivo específico se limitan a un motivo determinado para una transición determinada. Se procesan cuando se cumplen las condiciones siguientes:

  Reason field == "MyReason" &&
State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

En el ejemplo siguiente se restringe la modificación del campo de gravedad del cliente cuando el elemento de trabajo está en estado Activo.

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

¿Qué ocurre si se definen demasiadas reglas?

Se define una expresión SQL única por proyecto para validar los elementos de trabajo cada vez que se crean o actualizan. Esta expresión crece con el número de reglas que se especifican para todos los tipos de elementos de trabajo definidos para el proyecto. Cada calificador de comportamiento especificado para un campo da como resultado un aumento en el número de subexpresiones. Las reglas anidadas, reglas que solo se aplican en una transición o condicionadas en el valor de algún otro campo, hacen que se agreguen más condiciones a una IF instrucción . Una vez que la expresión alcanza un tamaño o complejidad determinado, SQL no puede evaluarla más y genera un error. La eliminación de algunas WIT o la eliminación de algunas reglas puede resolver el error.

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.

Las reglas de elementos de trabajo no existen como una sola colección. Las reglas se generan y combinan dinámicamente a partir de diferentes orígenes de datos. La lógica de combinación es una sencilla, consolida reglas idénticas, pero no recorta las reglas en conflicto.

Reglas de omisión

En general, el motor de reglas valida todos los elementos de trabajo cuando los usuarios modifican el elemento de trabajo. Sin embargo, para admitir determinados escenarios, los usuarios asignados a las reglas de omisión en las actualizaciones de elementos de trabajo del permiso de nivel de proyecto pueden guardar elementos de trabajo sin que se evalúen las reglas.

Las reglas se pueden omitir de una de estas dos maneras. La primera es a través de la API REST Elementos de trabajo: actualice y establezca el bypassRules parámetro en true. El segundo es a través del modelo de objetos de cliente, inicializando en modo bypassrules (inicializar WorkItemStore con WorkItemStoreFlags.BypassRules).

Campos del sistema y reglas personalizadas

Los campos del sistema tienen Sistema.Nombres de referencia de nombre, por ejemplo System.Title y System.State.

Los siguientes campos del sistema deben tener un valor: Id. de área, Fecha de cambio, Fecha de creación, Creado por, Estado y Motivo.

El motor de reglas restringe la configuración de condiciones o acciones a los campos del sistema, excepto los siguientes:

• Puede hacer que los campos Estado y Motivo sean de solo lectura.
• Puede aplicar la mayoría de las reglas a los campos Título, Asignado a, Descripción y Modificado por .

Si no ve un campo que aparece en el menú desplegable de la interfaz de usuario de regla para el proceso de herencia, este es el motivo. Por ejemplo, si intenta hacer que la ruta de acceso del área (System.AreaPath) sea de solo lectura en función de una condición, el campo Ruta de acceso del área no está disponible para la selección. Incluso si puede especificar un campo del sistema, el motor de reglas puede impedir que guarde la regla.

Reglas predeterminadas y de copia

Las reglas predeterminadas y de copia modifican los valores de los campos de elemento de trabajo. Definen el comportamiento y las restricciones en tiempo de ejecución, como especificar valores predeterminados, borrar campos, requerir que se definan los campos y mucho más.

Puede restringir la aplicación de estas reglas en función de la pertenencia a grupos del usuario actual, tal como se describe en Restricciones de reglas de pertenencia a grupos o usuarios.

Proceso de herencia

La mayoría de estas acciones de regla se pueden aplicar con la selección de cualquier condición.

Acción de proceso heredado

Descripción

Copy the value from...

Especifica otro campo que contiene un valor que se va a copiar en el campo actual.

Clear the value of...

Borra el campo de cualquier valor que contenga.

Use the current time to set the value of ...

Establece la hora de un campo en función de la configuración de hora del usuario actual.

Proceso XML local

Estas reglas admiten la configuración predeterminada, la copia de valores de un campo a otro o la aplicación de un valor de campo para que coincida con un patrón prescrito. Para obtener la estructura y los ejemplos de sintaxis, vea Definir un valor predeterminado o copiar un valor en un campo.

Elemento XML

Uso

COPY

Copia un valor especificado en un campo cuando un usuario crea o modifica un elemento de trabajo.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
   <COPY from="value" value=" " />  
</FIELD> 

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, se omite la DEFAULT regla. Las reglas predeterminadas solo se ejecutan si el Is valor del campo está vacío actualmente. Los valores admitidos incluyen la hora actual (from = "clock"), el usuario actual (from = "currentuser"), un valor literal (from = "value" value = "literal") o el valor de otro campo (from = field field = "referenceNameField").

<FIELD refname="MyCorp.Priority" name="Priority" type="String" 
<HELPTEXT>Specify the severity of the problem</HELPTEXT 
   <ALLOWEDVALUES 
      <LISTITEM value="P1"/ 
      <LISTITEM value="P2"/ 
      <LISTITEM value="P3"/ 
   </ALLOWEDVALUES 
<DEFAULT from="value" value="P3"/ 
</FIELD 

SERVERDEFAULT

Especifica el reloj del servidor o el usuario actual para definir un valor de campo.

<TRANSITION from="New" to="Active">  
   <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.StartWork" />  
   </ACTIONS>  
   <REASONS>  
      <DEFAULTREASON value="Work started" />  
   </REASONS>  
   <FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
            <COPY from="currentuser" />  
            <VALIDUSER />  
            <REQUIRED />  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
         <SERVERDEFAULT from="clock" />  
      </FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser" />  
      </FIELD>  
   </FIELDS>  
</TRANSITION>  

Reglas de restricción

Las reglas de restricción restringen el cambio del valor de un campo. Definen los estados válidos para un elemento de trabajo. Cada restricción funciona en un solo campo. Las restricciones se evalúan en el servidor en el guardado del elemento de trabajo y, si se infringe alguna restricción, se rechaza la operación de guardado.

Puede restringir la aplicación de estas reglas en función de la pertenencia a grupos del usuario actual, tal como se describe en Restricciones de reglas de pertenencia a grupos o usuarios.

Proceso de herencia

La mayoría de estas acciones de regla se pueden aplicar con la selección de cualquier condición.

Acción de proceso heredado

Descripción

Hide the field...
Solo está disponible cuando se selecciona una condición de pertenencia a grupos.

Especifica que no se muestra el campo en el formulario de elemento de trabajo, lo que básicamente elimina la capacidad de que el usuario actual cambie el valor del campo.

Make read-only

Impide que un campo se modifique en absoluto. Es posible que quiera aplicar esta regla en determinadas condiciones. Por ejemplo, después de cerrar un elemento de trabajo, quiere hacer que un campo sea de solo lectura para conservar los datos con fines de informes.
Para especificar que el campo predeterminado es de solo lectura, especifique en el cuadro de diálogo Editar campo, pestaña Opciones .

Make required

Requiere que un usuario especifique un valor para el campo. Los usuarios no pueden guardar un elemento de trabajo hasta que hayan asignado valores a todos los campos obligatorios.
Para especificar el valor predeterminado del campo, especifique en el cuadro de diálogo Editar campo, pestaña Opciones .

Proceso XML local

Elemento XML

Uso

ALLOWEDVALUES

Define una lista de valores permitidos para el campo. Los valores permitidos son valores que están disponibles para la selección en una lista de campos en formularios de elementos de trabajo y en el generador de consultas. Debe seleccionar uno de estos valores.

CANNOTLOSEVALUE

Impide que los usuarios borren un campo de un valor una vez que se haya especificado un valor. Este elemento mantiene el valor del campo actual y no se puede borrar ni dejar vacío.

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <CANNOTLOSEVALUE /> 
</FIELD> 

FROZEN

Impide que los usuarios cambien el valor de un campo una vez que contiene un valor. En cuanto un usuario guarda el elemento de trabajo con un valor en ese campo, el valor ya no se puede modificar. Un campo inmovilizado no se puede cambiar a ningún valor no vacío después de confirmar los cambios. Sin embargo, puede borrar manualmente el campo, guardar el elemento de trabajo y, a continuación, especificar un valor diferente.

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <FROZEN not="[Project]\Management Team" /> 
</FIELD> 

EMPTY

Borra el campo de cualquier valor que contenga y, a continuación, hace que el campo sea de solo lectura cuando un usuario guarda el elemento de trabajo. No debe usar EMPTY con READONLY.
EMPTY se usa principalmente durante la transición de estado para borrar los campos que se aplican al estado al que realiza la transición el elemento.

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

MATCH

Fuerza las entradas realizadas a un campo String para ajustarse a un patrón especificado de caracteres o números. Si define varios MATCH elementos, el valor se considera válido si coincide con alguno de los patrones que especifique. Si al menos un elemento se realiza correctamente, el campo tiene un valor válido.

<FIELD refname="MyCorp.GitHubURL" name="GitHub URL" type="String">  
   <MATCH pattern="https:\/\/github\.com\/\S+[\.md|\.yml]$"/>  
</FIELD>

NOTSAMEAS

Impide que un campo se asigne el mismo valor que el que se asignó a otro campo.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <NOTSAMEAS field="MyCorp.SubStatus" /> 
</FIELD> 

PROHIBITEDVALUES

Define una lista de valores prohibidos para el campo. Si se aplican varias reglas o PROHIBITEDVALUES a ALLOWEDVALUES un campo determinado, la lista completa de valores válidos es la intersección de todas las listas de valores permitidos(o todo, si no hay listas de valores permitidos, menos), es decir, establecer la diferencia, la unión de todas las listas de valores prohibidos.

READONLY

Impide que un campo se modifique en absoluto. Es posible que quiera aplicar esta regla en determinadas condiciones. Por ejemplo, después de cerrar un elemento de trabajo, quiere hacer que un campo sea de solo lectura para conservar los datos con fines de informes.
No use READONLY con el EMPTY elemento porque EMPTY también hace que un campo sea de solo lectura. La combinación de estos elementos puede producir resultados incoherentes.
Además, puede hacer que un campo aparezca como de solo lectura desde el formulario de elemento de trabajo mediante el Control atributo element ReadOnly . Otros clientes pueden escribir el campo en el campo, pero no a través del formulario de elemento de trabajo.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <READONLY />  
</FIELD> 

REQUIRED

Requiere que un usuario especifique un valor para el campo. Los usuarios no pueden guardar un elemento de trabajo hasta que hayan asignado valores a todos los campos obligatorios.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <REQUIRED />  
</FIELD> 

Listas desplegables

Las listas de selección definen los valores que un usuario puede o no puede elegir para un campo String o Integer. Los valores definidos en una lista de selección aparecen en un formulario de elemento de trabajo y en el editor de consultas.

Proceso de herencia

Para un proceso heredado, las listas de selección se definen mediante el cuadro de diálogo Editar campo.

Cuadro de diálogo Editar campo

Descripción

Pestaña Definición de un campo de lista desplegable

Define una lista de valores permitidos para el campo. Los valores permitidos son valores que están disponibles para la selección en una lista de campos en formularios de elementos de trabajo y en el generador de consultas. Debe seleccionar uno de estos valores.

Active la casilla Permitir que los usuarios escriban sus propios valores en la pestaña Opciones para permitir que los usuarios especifiquen sus propias entradas.

Define una lista de valores sugeridos para el campo. Los valores sugeridos son valores que están disponibles para la selección en una lista de campos en formularios de elementos de trabajo y en el generador de consultas. Puede escribir otros valores además de los de la lista.

Proceso XML local

Las listas de selección se definen mediante elementos XML enumerados en la tabla siguiente. Para obtener ejemplos y estructura de sintaxis, vea Definir listas de selección.

Puede combinar listas y expandir o listas de contratos. Además, puede restringir la aplicación de estas reglas en función de la pertenencia a grupos del usuario actual, tal como se describe en Restricciones de reglas de pertenencia a grupos o usuarios.

Elemento XML

Descripción

ALLOWEDVALUES

Define una lista de valores permitidos para el campo. Los valores permitidos son valores que están disponibles para la selección en una lista de campos en formularios de elementos de trabajo y en el generador de consultas. Debe seleccionar uno de estos valores.

ALLOWEXISTINGVALUE

Define el campo para permitir los valores existentes. Este elemento permite usar los valores de campo que ya existen, incluso si no son válidos. Todos los nuevos valores de campo deben ser válidos.

PROHIBITEDVALUES

Define una lista de valores prohibidos para el campo.

SUGGESTEDVALUES

Define una lista de valores sugeridos para el campo. Los valores sugeridos son valores que están disponibles para la selección en una lista de campos en formularios de elementos de trabajo y en el generador de consultas. Puede escribir otros valores además de los de la lista.

Campos de identidad y errores de validación

Para evitar errores de validación que se producirían cuando los miembros abandonan el equipo y ya no están 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>

Cambios o valores de campo condicionales

Las reglas condicionales especifican una acción basada en el valor de un campo que es igual o no es igual a un valor específico, o si se realizó un cambio o no en el valor de un campo específico. En general, las reglas condicionales se aplican primero sobre las reglas incondicionales. Cuando varias reglas condicionales se evalúan como true, el orden de ejecución es: When, WhenNot, WhenChanged, WhenNotChanged.

Proceso de herencia

Puede especificar varias reglas condicionales por campo. Sin embargo, solo puede especificar un único campo de conducción por regla condicional.

Condición heredada

Descripción

The value of ... (equals) [Cuándo]

Especifica una o varias reglas que se aplicarán al campo actual cuando otro campo tiene un valor específico.

A change was made to the value of ... [WhenChanged]

Aplica una o varias reglas al campo actual cuando se cambia el valor de un campo específico.

The value of ... (not equals) [WhenNot]

Aplica una o varias reglas al campo actual cuando otro campo no tiene un valor específico.

No change was made to the value of ... [WhenNotChanged]

Aplica una o varias reglas al campo actual cuando no se cambia el valor de un campo específico.

Acción heredada

Descripción

Clear the value of ...
Copy the value from ...
Make read-only ...
Make required ...
Set the value of ...
Use the current time to set the value of ...
Use the current user to set the value of ...

Especifica la acción que se va a realizar en un campo específico.

Proceso XML local

Los siguientes elementos XML se usan para establecer condiciones para cuando se evalúan otras reglas. Puede especificar varias reglas condicionales por campo. Sin embargo, solo puede especificar un único campo de conducción por regla condicional. No se pueden anidar reglas condicionales. Las acciones admitidas para cada modelo de proceso incluyen las enumeradas en la tabla siguiente.

Para obtener ejemplos y estructura de sintaxis, consulte Asignación de reglas y valores basados en condicionales. Puede restringir la aplicación de estas reglas en función de la pertenencia a grupos del usuario actual, tal como se describe en Restricciones de reglas de pertenencia a grupos o usuarios.

Elemento XML

Uso

WHEN

Especifica una o varias reglas que se aplicarán al campo actual cuando otro campo tiene un valor específico. El elemento primario define el campo actual.
Cuando el campo especificado tiene el valor especificado, las reglas de este elemento se aplican al campo actual.

WHENCHANGED

Especifica una condición en la que se aplicarán una o varias reglas al campo actual. Las reglas se aplican al campo actual cuando se cambia el valor de otro campo en una revisión a un elemento de trabajo. El elemento primario define el campo actual.

WHENNOT

Especifica una condición en la que se aplicarán una o varias reglas al campo actual. Las reglas se aplican al campo actual cuando cambia el valor de otro campo. El elemento primario define el campo actual.
Cuando el campo especificado no contiene el valor especificado, las reglas de este elemento se aplican al campo actual.

WHENNOTCHANGED

Especifica una condición en la que se aplicarán una o varias reglas al campo actual. Las reglas se aplican al campo actual cuando el valor de otro campo no cambia en una revisión a un elemento de trabajo. El elemento primario define el campo actual.

Restricciones de reglas de pertenencia a grupos o usuarios

Puede restringir la aplicación de una regla en función de la pertenencia del usuario actual. Se recomienda limitar el ámbito de la regla a un grupo de seguridad de Azure DevOps y no a un solo usuario, aunque puede especificar este último. Para que la regla tenga el ámbito de varios grupos, debe crear un grupo primario de Azure DevOps que incluya el conjunto de grupos que desea usar.

Implementación de procesos

Sugerencia

Para evitar problemas de evaluación de reglas que pueden surgir, especifique los grupos de seguridad de Azure DevOps y no el identificador de Microsoft Entra o los grupos de seguridad de Active Directory. Para más información, consulte Reglas predeterminadas y el motor de reglas.

Proceso de herencia

Como se indica en la tabla siguiente, para restringir una regla basada en la pertenencia del usuario actual, especifique una de las dos condiciones para un proceso heredado. Estas reglas están activas para Azure DevOps 2020 y versiones posteriores.

Se aplica a

Regla

Condición

Current user is a member of group ...
Current user is not member of group ...

Action

Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...

Proceso XML local

Para restringir una regla basada en la pertenencia del usuario actual, especifique los for atributos o not en el elemento rule. Especifique el ámbito de la regla. Para que la regla tenga el ámbito de varios grupos, debe crear un grupo primario de Azure DevOps que incluya el conjunto de grupos que desea usar.

Escenario

Uso

Crear un campo necesario solo para un grupo especificado

Use for para aplicar una regla a un grupo. En este ejemplo se requiere que cualquier usuario del grupo Analistas junior complete el campo Second Approver (Segundo aprobador).

<FIELD name="Second Approver">
<REQUIRED for="Example1\Junior Analysts"/>
</FIELD>

Restricción de la modificación de un campo a un grupo de usuarios

Use not para excluir un grupo de una regla. En este ejemplo se define el campo Descripción de evaluación de prioridades como de solo lectura para todos los usuarios, excepto los usuarios del grupo Comité de evaluación de prioridades.

<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>

Crear un campo necesario para algunos usuarios y no para otros

Use una combinación de for y not para aplicar simultáneamente una regla a algunas y no a otras. En este ejemplo se define gravedad como un campo obligatorio para los usuarios del grupo Miembros del proyecto, pero no para los del grupo Project Administración s. Si un usuario está en ambos grupos, se aplicará la for instrucción y se requerirá el campo.

<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>

Uso de tokens para hacer referencia a usuarios o grupos

Los campos de identidad o selector de personas pueden aceptar valores que hacen referencia a usuarios y grupos. Al restringir una regla a un grupo, se indica el dominio o el ámbito del grupo. Para algunos valores, puede usar tokens.

Proceso de herencia

Entre los ejemplos de tokens se incluyen los siguientes:

• [ProjectName], como [Fabrikam], [FabrikamFiber], [MyProject]
• [OrganizationName], como [fabrikam], [myorganization]
• [CollectionName], como [fabrikam], [myorganization]

Para obtener información sobre los ámbitos disponibles para el proyecto u organización, vaya a la página Project Configuración> Permissions>Groups or Organization Configuración> Permissions Groups (Grupos de Configuración Permissions),> puede filtrar la lista según sea necesario. Por ejemplo, en la imagen siguiente se muestran las cuatro primeras entradas en una lista filtrada basada en Azure DevOps. Para más información, consulte Cambio de permisos de nivel de proyecto o Cambio de permisos de nivel de colección de proyectos.

Proceso XML local

Entre los ejemplos de tokens se incluyen los siguientes:

• [Project], como [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approvers El token [Project] especifica un grupo definido para un proyecto. Esto puede corresponder a un equipo, a un grupo de seguridad predeterminado o personalizado, o a un grupo de Active Directory que se ha agregado al proyecto.
• [GLOBAL], para hacer referencia a un grupo con ámbito de colección, por ejemplo, [GLOBAL]\Colección de proyectos Administración istrators Use [GLOBAL] para hacer referencia a un grupo de seguridad con ámbito de colección, como el grupo colección de proyectos Administración istrators o un grupo de Windows agregado a una colección. Por ejemplo:

  <FIELD name="Title">
      <READONLY for="[GLOBAL]\Project Collection Valid Users"/>
  </FIELD>
  

• [Team Foundation] para hacer referencia a un grupo con ámbito de servidor, por ejemplo, [Team Foundation]\Team Foundation Administración istrators Use [Team Foundation] para hacer referencia a un grupo con ámbito de servidor, como un grupo integrado o un grupo de Windows que agregue a un grupo de nivel de servidor. Por ejemplo:

  <FIELD name="Title">
      <READONLY for="[Team Foundation]\Team Foundation Valid Users"/>
  </FIELD>
  

• [DomainName] para hacer referencia a un grupo con ámbito de servidor, por ejemplo, [Team Foundation]\Team Foundation Administración nombre de cuenta calificado por dominio, como el que se muestra en el ejemplo siguiente, se puede usar para hacer referencia a un usuario o grupo de dominio. Algunas reglas solo admiten grupos y no admiten la referencia a usuarios de dominio.

  <LISTITEM value="FABRIKAM\Christie Church's Direct Reports"/>
  

Nota:

[Project], [GLOBAL] y [Team Foundation] se usan tal como está. No los reemplaza por el nombre del proyecto, la colección o el nombre del servidor.

Para obtener información sobre los ámbitos disponibles para el proyecto o la colección, vaya a la página Project Configuración Permissions>Groups or Collection Configuración> Permissions Groups (Grupos de project Configuración> Permissions>Groups). Filtre la lista según sea necesario. Por ejemplo, en la imagen siguiente se muestran las cuatro primeras entradas en una lista filtrada basada en Azure DevOps. Para más información, consulte Cambio de permisos de nivel de proyecto o Cambio de permisos de nivel de colección de proyectos.

Todos los usuarios y grupos deben estar calificados por uno de estos tokens. Por ejemplo, el siguiente XML no es válido porque no califica el grupo especificado con un token válido.

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

Para más información sobre los grupos de seguridad predeterminados, consulte Permisos y grupos.

Evaluación de reglas

Las reglas que especifican una condición basada en la pertenencia de usuario o grupo del usuario que modifica un elemento de trabajo se evalúan de dos maneras. Cuando se evalúa la regla, la aplicación debe determinar si la regla se aplica al usuario actual comprobando si ese usuario es o no es miembro del grupo especificado.

• Al modificar el elemento de trabajo desde el portal web, la API REST o el comando azure boards , se realiza una solicitud al identificador de Microsoft Entra o Active Directory. No se producen problemas para esta operación.
• Al modificar el elemento de trabajo desde Visual Studio, Excel u otra herramienta personalizada mediante el modelo de objetos de cliente WIT, la solicitud para evaluar la pertenencia se basa en una caché de cliente. La caché de cliente no es consciente de los grupos de Active Directory.

Nota:

Visual Studio 2019 Team Explorer para proyectos que usan GIT se ha vuelto a escribir para usar las API REST.

Para evitar problemas con los usuarios que actualizan elementos de trabajo de varios clientes, especifique grupos de seguridad de Azure DevOps en lugar de grupos de Active Directory. Puede crear fácilmente un grupo de seguridad de Azure DevOps para que se corresponda con un grupo de Active Directory. Para obtener información sobre cómo, consulte Agregar o quitar usuarios o grupos, administrar grupos de seguridad.

Nota:

El OM del cliente WIT está en desuso. A partir del 1 de enero de 2020, ya no se admite cuando se trabaja con Azure DevOps Services y Azure DevOps Server 2020.

Orden en el que se evalúan las reglas

Normalmente, las reglas se procesan en la secuencia en la que se enumeran. Sin embargo, la secuencia completa para la evaluación de todas las reglas no es totalmente determinista.

En esta sección se describen el comportamiento esperado y las interacciones cuando se aplican reglas condicionales, de copia y predeterminadas.

Proceso de herencia

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

1. Desde un cliente de Azure DevOps, como el portal web o Visual Studio Team Explorer, un usuario crea un nuevo elemento de trabajo o edita un elemento de trabajo existente.

2. Rellene los valores predeterminados del campo. Para todos los campos, aplique los valores predeterminados asignados al campo que no formen parte de una cláusula condicional.

3. Copie o establezca valores de campo. Para todos los campos, aplique las reglas para copiar un valor o establecer el valor de un campo que no forme parte de una cláusula condicional.

4. Para todos los campos con una regla condicional When que coincida, aplique reglas para establecer o copiar un valor de campo.

5. Para todos los campos con una regla condicional When Not que coincida, aplique reglas para establecer o copiar un valor de campo.

   El sistema siempre procesa las reglas When before When Not .

6. Para todos los campos que han cambiado sus valores desde el paso 1 y que contienen reglas When Changed , aplique reglas para establecer o copiar un valor de campo.

7. Permitir al usuario iniciar la edición.

8. El usuario cambia un valor de campo y, a continuación, mueve el foco del campo.

9. Procese las reglas When para ese campo que coincidan con el nuevo valor.

10. Procese las reglas When Not para ese campo que coincidan con el nuevo valor.

11. Procese las reglas When Changed para ese campo que coincidan con el nuevo valor.

12. Devolver la capacidad de edición al usuario.

13. El usuario guarda los cambios en el almacén de datos.

14. Para todos los campos, aplique las Use the current time to set the value of ... acciones definidas para el campo directamente o indirectamente bajo una regla condicional.

Proceso XML local

Normalmente, las reglas se procesan en la secuencia en la que se enumeran. Sin embargo, cuando se usan los elementos WHEN, DEFAULT y COPY , se pueden aplicar comportamientos adicionales. Los pasos siguientes muestran, en la secuencia correcta, las interacciones que realiza Azure DevOps y por el usuario de un formulario de elemento de trabajo. El usuario solo realiza los pasos 1, 8 y 13.

1. Desde un cliente de Azure DevOps, como el portal web o Visual Studio Team Explorer, un usuario crea un nuevo elemento de trabajo o edita un elemento de trabajo existente.

2. Rellene los valores predeterminados del campo. Para todos los campos, aplique las reglas DEFAULT especificadas fuera o WHEN .

3. Copiar valores de campo. Para todos los campos, use las reglas COPY que estén fuera de las cláusulas WHEN .

4. Para todos los campos con una regla WHEN que coincida, primero realice DEFAULT y, a continuación , copie las reglas dentro.

5. Para todos los campos con una regla WHENNOT que coincida, primero realice DEFAULT y, a continuación , copie las reglas dentro.

   El sistema siempre procesa las reglas WHEN antes de las reglas WHENNOT .

6. Para todos los campos que han cambiado sus valores desde el paso 1 y que contienen reglas WHENCHANGED , primero realice DEFAULT y, a continuación , copie las reglas dentro.

7. Permitir al usuario iniciar la edición.

8. El usuario cambia un valor de campo y, a continuación, mueve el foco del campo.

9. Genere cualquier regla WHEN para ese campo que coincida con el nuevo valor.

10. Genere cualquier regla WHENNOT para ese campo que coincida con el nuevo valor.

11. Genere las reglas WHENCHANGED para ese campo que coincidan con el nuevo valor.

12. Devolver la capacidad de edición al usuario.

13. El usuario guarda los cambios en la base de datos.

14. Para todos los campos, realice operaciones SERVERDEFAULT definidas para el campo directamente o indirectamente bajo una regla WHEN o WHENNOT.

Entradas de pulsación de tecla y evaluación de reglas

El sistema establece un nuevo valor para un campo cada vez que un usuario escribe una pulsación de tecla dentro de un campo mediante el formulario de elemento de trabajo. Esto significa que una regla condicional puede producirse de forma inesperada siempre que se cumplan las condiciones de requisitos previos de la regla.

En el siguiente ejemplo XML, el sistema vacía MyCorp.SubStatus mientras escribe "Aprobado de nuevo" en el campo Estado porque la regla WHEN se produce tan pronto como el usuario escribe la letra "e" en Aprobado, incluso si el valor final previsto no es "Aprobar". Por este motivo, piense detenidamente cuando use reglas condicionales.

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

Artículos relacionados

• Escenarios de reglas de ejemplo
• Índice de campo de elemento de trabajo
• Atributos y campos de elementos de trabajo
• Cambiar los permisos de nivel de proyecto
• Cambiar los permisos de nivel de colección de proyectos
• Permisos y grupos
• Proceso heredado
  • Agregar una regla personalizada a un tipo de elemento de trabajo
  • Aplicación de reglas a estados de flujo de trabajo
• Proceso XML local
  • Definir un valor predeterminado o copiar un valor en un campo
  • Definir listas de selección
  • Asignación de reglas y valores basados en condicional