Aplicar reglas a estados de flujo de trabajo (proceso de herencia)

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

Después de agregar o modificar los estados de flujo de trabajo para un tipo de elemento de trabajo, defina las reglas que se aplican en función del cambio de estado del flujo de trabajo. La adición de reglas a estados de flujo de trabajo admite los siguientes escenarios:

• Compatibilidad con un proceso de aprobación
• Impedir que los usuarios no autorizados establezcan un estado no válido
• Realizar un campo requerido o de solo lectura u otro valor en función de los cambios de estado
• Restringir la transición de un estado a otro
• Restringir o permitir transiciones de estado a usuarios o grupos específicos
• Mantenimiento de un proceso de flujo de trabajo controlado y compatibilidad con los requisitos de auditoría
• Automatización del cierre de elementos de trabajo primarios

Requisitos previos

Para aplicar reglas a los estados de flujo de trabajo en Azure DevOps, necesita permisos y niveles de acceso específicos:

• Permisos:

  • Ser administrador de proyectos para administrar grupos de seguridad y permisos en el nivel de proyecto, que incluye reglas de configuración para estados de flujo de trabajo.
  • Tener el permiso Seguimiento de elementos de trabajo, que permite administrar el área de seguimiento del trabajo, que se puede conceder a los miembros del grupo Administradores de proyectos o a través de permisos específicos.

• Niveles de acceso:

  • Tener acceso básico , que suele ser suficiente para la mayoría de los usuarios que necesitan administrar elementos de trabajo y aplicar reglas a los estados de flujo de trabajo.

Descripción de las reglas de flujo de trabajo

En la tabla siguiente se describen los tres grupos de reglas de flujo de trabajo que puede definir:

1. Acciones estándar:

   • Se aplica cuando se crea un elemento de trabajo, en un estado seleccionado o se mueve de un estado a otro.
   • Las acciones incluyen establecer el valor de un campo, hacer que un campo sea de solo lectura o hacer necesario un campo.
   • Puede especificar una o dos condiciones y varias acciones.

2. Restricción de las transiciones de estado (grupo 1):

   • Especifique una condición que indique el estado del que se ha movido un elemento de trabajo.
   • Defina acciones para restringir las transiciones de ese estado a otros estados.

3. Restricción de transiciones de estado (grupo 2):

   • De forma similar al primer grupo, especifique una condición que indique el estado desde el que se ha movido un elemento de trabajo.
   • Defina acciones para restringir las transiciones de ese estado a otros estados.

---

Condición

Acciones admitidas

---

Establecer el valor de campo o hacer que sea de solo lectura o necesario en función del estado

---

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

---

Nota:

Al personalizar un proceso heredado, los proyectos que usan ese proceso reflejan automáticamente las personalizaciones. Para garantizar una transición sin problemas, se recomienda crear un proceso de prueba y un proyecto, lo que le permite probar las personalizaciones antes de implementarlas en toda la organización. Para obtener más información, consulte Creación y administración de procesos heredados.

Descripción de los límites de estado y reglas de flujo de trabajo

Las reglas de flujo de trabajo se aplican al agregar o modificar elementos de trabajo a través de cualquiera de las interfaces siguientes:

• Portal web: formulario de elemento de trabajo, actualizaciones masivas, actualizaciones en la vista de consulta
• Portal web: Panel o Panel de tareas, mover el elemento de trabajo a la columna
• Formulario de elemento de trabajo de Visual Studio 2017 y versiones anteriores
• Formato de archivo CSV: importación o actualización masiva
• Excel: importación o actualización masiva
• API REST: Agregar o modificar elementos de trabajo

En la tabla siguiente se resumen los límites de estado y regla del flujo de trabajo para el proceso de herencia.

Object	Límite de herencia
Tipos de elementos de trabajo definidos para un proceso	64
Estados de flujo de trabajo definidos para un tipo de elemento de trabajo	32
Reglas definidas para un tipo de elemento de trabajo	1024

Al definir reglas y estados de flujo de trabajo, siga estas directrices para minimizar los problemas de rendimiento:

• Limitar el número de reglas de un WIT: aunque puede crear varias reglas para un tipo de elemento de trabajo (WIT), más reglas pueden afectar negativamente al rendimiento cuando los usuarios agregan o modifican elementos de trabajo. El sistema valida todas las reglas asociadas a los campos del tipo de elemento de trabajo cuando los usuarios guardan elementos de trabajo. En algunos casos, la expresión de validación de reglas podría ser demasiado compleja para que SQL se evalúe.
• Limitar el número de tipos de elementos de trabajo personalizados: reducir el número de tipos de elementos de trabajo personalizados puede ayudar a mantener un rendimiento óptimo.

Definición de una regla

Antes de definir una regla basada en estados de flujo de trabajo, asegúrese de que se han implementado los siguientes elementos:

• Estados de flujo de trabajo: defina los estados de flujo de trabajo tal y como se describe en Personalización de un flujo de trabajo.
• Campos personalizados: si la regla requiere un campo personalizado, agréguelo al tipo de elemento de trabajo tal y como se describe en Agregar y administrar campos.
• Grupos de seguridad: si la regla requiere que un grupo de seguridad conceda o restrinja los cambios basados en la pertenencia a usuarios o grupos, defina el grupo de seguridad tal y como se describe en Agregar o quitar usuarios o grupos, administre grupos de seguridad.

Para obtener más información sobre cómo definir reglas, vea Agregar una regla personalizada.

Establecer el valor de campo o hacer que el campo sea de solo lectura o obligatorio

Con la primera agrupación de reglas, puede especificar una o dos condiciones y hasta 10 acciones por regla.

Ejemplo de garantía de aprobación de responsable de equipo antes del trabajo activo

En este ejemplo, los equipos de desarrollo quieren asegurarse de que no se trabaja en ningún caso de usuario hasta que un responsable del equipo lo apruebe. Los estados de flujo de trabajo predeterminados se usan, con la adición de un campo personalizado, Aprobado por y un grupo de seguridad, Grupo de clientes potenciales del equipo.

Estados de flujo de trabajo predeterminados

Requisitos de reglas

Para garantizar la aprobación antes del trabajo activo, defina las reglas siguientes:

• Requerir que el campo Aprobado por se rellene cuando el estado pase de Nuevo a Activo
• Restrinja a los usuarios que no están en el grupo de clientes potenciales del equipo rellenando el campo Aprobado por
• Desactive el campo Aprobado por cuando el estado se mueve a Nuevo o Quitado

Definiciones de las reglas

Los requisitos de regla se traducen a las cuatro definiciones de reglas siguientes.

---

Nombre de regla

Condición

Acciones

---

Aprobado por borrado cuando nuevo

Cuando A work item state changes to New

Entonces Clear the value of Approved By

Aprobado por borrado cuando se quita

Cuando A work item state changes to Removed

Entonces Clear the value of Approved By

Aprobado por solo lectura

Cuando Current user is not member of group Team Leads Group

Entonces Make read-only Approved By

Aprobado por obligatorio

Cuando A work item state changes from New to Active

Entonces Make required Approved By

---

Restricción de las transiciones de estado

Al especificar la condición , A work item state moved from ...solo puede especificar esa condición. Puede especificar hasta 10 acciones.

Ejemplo de restricción de transiciones de estado y estado aprobado

Los siguientes estados de flujo de trabajo se definen para el caso de usuario. Los estados heredados Nuevo, Resuelto y Quitado están ocultos. En su lugar, se usan los estados propuestos, en revisión y corte. Además, se definen tres Estados más: Investigar, Diseñar y Aprobar. Estos Estados deben seguir la secuencia como se muestra en la siguiente imagen.

Sin restricciones, los usuarios pueden pasar de un estado a otro estado, tanto hacia delante como hacia atrás dentro de la secuencia.

Requisitos de reglas

Para admitir un flujo de trabajo más controlado, el grupo empresarial decidió establecer reglas que admitan las siguientes transiciones de estado hacia delante e inverso en el tipo de elemento de trabajo Caso de usuario.

Valor	Regla de transición
Propuesto	Solo puede moverse a Investigación y Corte
Investigar	Solo se puede mover a Diseño y Cortar
Diseño	Solo se puede mover a Investigación, Aprobado y Cortar
Aprobados	Solo se puede mover a Diseño, Activo y Cortar
Activas	Solo se puede mover a En revisión
En revisión	Solo se puede mover a Activo (más trabajo encontrado), Cerrado o Cortado
Cerrada	Puede pasar a Research, Design, Active, In Review (Permite casos en los que el usuario cerró el elemento de trabajo en error)
Cortar	solo se puede mover a Propuesta

Nota:

Al restringir las transiciones de estado, tenga en cuenta los casos en los que un usuario podría mover un estado en error. Asegúrese de que los usuarios pueden recuperarse correctamente.

Además, el grupo de negocios quiere aplicar las siguientes reglas para los campos obligatorios:

• Requerir que el campo Aprobado por se rellene cuando el estado pase de Aprobado a Activo.
• Permitir que solo los usuarios del grupo Aprobadores autorizados rellenen el campo Aprobador por .
• Desactive el campo Aprobado por cuando el estado se mueva a Cortar.
• Requerir que el campo Criterios de aceptación se rellene cuando el estado se mueva a Activo.

Definiciones de las reglas

Para implementar las restricciones mencionadas anteriormente, el administrador de procesos agrega un campo personalizado Aprobado por identidad, un grupo de seguridad aprobadores autorizados y las siguientes reglas.

---

Nombre de regla

Condición

Acciones

---

Estado propuesto

Cuando A work item state moved from Proposed

Entonces Restrict the state transition to Design
Y Restrict the state transition to Approved
Y Restrict the state transition to Active
Y Restrict the state transition to In Review
Y Restrict the state transition to Closed

Estado de investigación

Cuando A work item state moved from Research

Entonces Restrict the state transition to Proposed
Y Restrict the state transition to Approved
Y Restrict the state transition to Active
Y Restrict the state transition to In Review
Y Restrict the state transition to Closed

Estado de diseño

Cuando A work item state moved from Design

Entonces Restrict the state transition to Proposed
Y Restrict the state transition to Research
Y Restrict the state transition to Active
Y Restrict the state transition to In Review
Y Restrict the state transition to Closed

Estado aprobado

Cuando A work item state moved from Approved

Entonces Restrict the state transition to Proposed
Y Restrict the state transition to Research
Y Restrict the state transition to Design
Y Restrict the state transition to In Review
Y Restrict the state transition to Closed

Estado activo

Cuando A work item state moved from Active

Entonces Restrict the state transition to Proposed
Y Restrict the state transition to Research
Y Restrict the state transition to Design
Y Restrict the state transition to Approved
Y Restrict the state transition to Closed

En estado de revisión

Cuando A work item state moved from In Review

Entonces Restrict the state transition to Proposed
Y Restrict the state transition to Research
Y Restrict the state transition to Design
Y Restrict the state transition to Approved

Estado cerrado

Cuando A work item state moved from Closed

Entonces Restrict the state transition to Proposed
Y Restrict the state transition to Cut

Estado de corte

Cuando A work item state moved from Cut

Entonces Restrict the state transition to Research
Y Restrict the state transition to Design
Y Restrict the state transition to Approved
Y Restrict the state transition to Active
Y Restrict the state transition to In Review
Y Restrict the state transition to Closed

Campos obligatorios de estado aprobados

Cuando A work item changes from Approved to Active

Entonces Make required Acceptance Criteria
Y Make required Approved By

Aprobadores autorizados

Cuando Current user is not a member of Authorized Approvers

Entonces Make read-only Approved By

Borrar aprobado por campo

Cuando A work item state changes to Cut

Entonces Clear the value of Approved By

---

Comprobación de las restricciones de transición de estado

Una vez que defina las reglas para el proceso y actualice el proyecto, actualice el explorador. Compruebe las operaciones mediante el formulario de elemento de trabajo y el explorador.

Para las reglas definidas en la tabla anterior, compruebe los menús desplegables Estado. Abra la placa y asegúrese de que puede pasar de un estado a otro.

Propuesto	Investigación	Diseño	Aprobado
Activas	En Revisión	Closed	Cortar

Restricción de la transición de estado en función de la pertenencia a grupos o usuarios

Al especificar una de las dos condiciones basadas en la pertenencia a grupos o usuarios, Current user is member of group ... o Current user is not member of group ..., solo puede especificar una condición. Además, si especifica la acción Restrict the transition to state..., solo puede especificar una acción.

Nota:

Los elementos de trabajo están sujetos a las reglas aplicadas. Las reglas condicionales basadas en la pertenencia a usuarios o grupos se almacenan en la caché para el explorador web. Si se encuentras con restricciones para actualizar un elemento de trabajo, es posible que se haya encontrado con una de estas reglas. Si cree que se ha encontrado con un problema que no se aplica a su caso, consulte Formulario de elementos de trabajo, problemas de almacenamiento en caché de IndexDB.

Automatización de las transiciones de estado de los elementos de trabajo primarios

Para automatizar las transiciones de estado de los elementos de trabajo primarios basados en las asignaciones de estado de sus elementos de trabajo secundarios, consulte Automatización de transiciones de estado del elemento de trabajo.

Automatizar la reasignación en función del cambio de estado

Anteriormente, el tipo de elemento de trabajo de errores de proceso ágil tenía una regla que reasignaba el error a su creador. Hemos quitado esta regla del proceso del sistema predeterminado. Puede restablecer la regla o agregar una regla similar a otros tipos de elementos de trabajo mediante la siguiente condición y acción:

Cuando A work item state changes to se resuelve a continuaciónCopy the value from , se crea mediante para asignar a.

Artículos relacionados

• Adición de una regla personalizada
• Almacenamiento en caché de formularios de elemento de trabajo
• Acceso, exportación y filtrado de registros de auditoría
• Personalización de un flujo de trabajo