Reglas y evaluación de reglas

Para un proceso heredado, cada regla consta de dos partes: Condiciones y Acciones. Las condiciones definen las circunstancias que se deben cumplir para que se aplique la regla. Las acciones definen las operaciones que se deben 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 cumplen todas las condiciones para poder ejecutarse.

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

   (Condition) When a work item State is(Condition) When a work item State is
   (Condition) And when the value of(Condition) And when the value of = =
   (Action) Then make required(Action) Then make required

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

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. Y, a excepción del elemento , puede especificar estas reglas para que afecten durante una transición de flujo de trabajo o como elementos secundarios dentro de un elemento (flujo de HELPTEXTFIELD trabajo global).

Dónde aplicar una regla de campo

Si desea que una regla se aplique a un campo a lo largo de la vida del elemento de trabajo, es específico dentro de la FIELD sección . 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, si quiere que se aplique en función de un cambio en estado, motivo o transición, es especificarlo dentro de la WORKFLOW sección .

Los campos State (System.State) y Reason (System.Reason) se definen en la sección . 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 más información, consulte Cambio del flujo de trabajo de un tipo de elemento de trabajo.

De lo contrario, especifique una regla que solo deba evaluarse durante un cambio de estado. Estas reglas se definen dentro de la WORKFLOW sección bajo los elementos , o STATEREASONTRANSITION . Todas las reglas, excepto HELPTEXT , se pueden aplicar dentro de un elemento FIELD (Flujo de trabajo).

Las reglas de campo son aditivas. Es decir, puede especificar cuatro conjuntos de reglas para el mismo campo que evaluará 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 están en el ámbito de una instancia de elemento de trabajo cuando se encuentra 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 la transición que especifique para una transición específica están en el ámbito de un elemento de trabajo que está experimentando una transición determinada. 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 la razón que especifique para un motivo específico están en el ámbito de 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>

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

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. Para obtener la estructura de sintaxis y los ejemplos, vea Definir un valor predeterminado o copiar un valor en un campo.

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

<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 

<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>  

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

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

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, expandirlas o contraerlas. Además, puede restringir la aplicación de estas reglas en función de la pertenencia a grupos del usuario actual, como se describe en Restricciones de reglas de pertenencia a grupos o usuarios.

Campos de identidad y errores de validación

Para evitar errores de validación que de otro modo 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 proyecto.

<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>

Puede especificar varias reglas condicionales por campo. Sin embargo, solo puede especificar un único campo esencial por regla condicional.

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 esencial por regla condicional. No se pueden anidar reglas condicionales. Las acciones admitidas para cada modelo de proceso incluyen las que se enumeran en la tabla siguiente.

Para obtener ejemplos y estructura de sintaxis, vea 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.

Como se indica en la tabla siguiente, para restringir una regla en función de 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.

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

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

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

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

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 su proyecto u organización, vaya a la página grupos de permisos de Project Configuración o grupos de permisos Configuración de la organización, puede filtrar la lista según sea necesario. >> Por ejemplo, en la imagen siguiente se muestran las cuatro primeras entradas de una lista filtrada basada en Azure DevOps. Para más información, consulte Establecer permisos en el nivel de proyecto o colección.

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, un grupo de seguridad predeterminado o personalizado, o un grupo de Active Directory que se ha agregado al proyecto.
• [GLOBAL], para hacer referencia a un grupo de ámbito de colección, por ejemplo, [GLOBAL]\Project Collection Administrators Use [GLOBAL] para hacer referencia a un grupo de seguridad de ámbito de recopilación, como el grupo administradores de recopilación de Project o un grupo 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 de ámbito de servidor, por ejemplo, [Team Foundation]\Team Foundation Administrators Use [Team Foundation] para hacer referencia a un grupo de ámbito de servidor, como un grupo integrado o un grupo 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 de ámbito de servidor, por ejemplo, [Team Foundation]\Team Foundation Administrators Nombre de cuenta calificado por el 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"/>
  

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

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 califica el grupo especificado con un token válido.

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

Los pasos siguientes muestran, en la secuencia correcta, las interacciones que Azure DevOps realiza 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 Azure DevOps , como el portal web, Visual Studio/Team Explorer o Team Explorer Everywhere, un usuario crea un nuevo elemento de trabajo o edita un elemento de trabajo existente.

2. Rellene los campos predeterminados. Para todos los campos, aplique los valores predeterminados asignados al campo que no forman 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 establezca 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 Cuando no coincide, aplique reglas para establecer o copiar un valor de campo.

   El sistema siempre procesa las reglas When antes de las reglas When Not.

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

7. Permita que el usuario empiece a editar.

8. El usuario modifica un valor de campo y después quita 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 cuando se cambien para ese campo que coincidan con el nuevo valor.

12. Permita que el usuario vuelva a editar.

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

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

Las reglas normalmente se procesan en la secuencia en la que están presentes. Sin embargo, cuando se usan los elementos WHEN, DEFAULTy COPY, pueden aplicarse comportamientos adicionales. Los pasos siguientes muestran, en la secuencia correcta, las interacciones Azure DevOps realiza 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 Azure DevOps , como el portal web, Visual Studio/Team Explorer o Team Explorer Everywhere, un usuario crea un nuevo elemento de trabajo o edita un elemento de trabajo existente.

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

3. Copie los 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, las reglas COPY dentro.

5. Para todos los campos con una regla WHENNOT que coincida, primero realice default y, después, las reglas COPY 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 debe realizar default y, a continuación, copiar reglas dentro.

7. Permita que el usuario empiece a editar.

8. El usuario modifica un valor de campo y después quita el foco del campo.

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

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

11. Generar cualquier regla WHENCHANGED para ese campo que coincida con el nuevo valor.

12. Permita que el usuario vuelva a editar.

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

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

Entradas de pulsación de teclas 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 a través del formulario de elemento de trabajo. Esto significa que una regla condicional puede producirse inesperadamente siempre que se cumplan las condiciones de requisitos previos de la regla.

En el ejemplo XML siguiente, el sistema vacía MyCorp.SubStatus mientras escribe "Aprobado de nuevo" en el campo Estado porque la regla WHEN se produce en cuanto el usuario escribe la letra "e" en Aprobado, incluso si el valor final previsto no es "Aprobar". 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>