Aplicación de 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, es posible que desee definir una o varias reglas que se apliquen según el cambio de estado del flujo de trabajo. Agregar 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 para admitir los requisitos de auditoría
• Automatización del cierre de elementos de trabajo primarios

Revise este artículo para comprender cómo definir reglas que se aplican al cambiar un estado de flujo de trabajo.

• Descripción de los tipos de reglas de flujo de trabajo
• Límites de estado y reglas de flujo de trabajo y procedimientos recomendados
• Establecer un valor de campo o hacer que un campo sea de solo lectura o necesario en función de la selección de estado
• Restringir las transiciones de estado
• Restringir o permitir transiciones de estado a usuarios o grupos específicos
• Automatizar las transiciones de estado de los elementos de trabajo primarios

Importante

Este artículo se aplica a Azure DevOps Services y Azure DevOps Server 2019 y versiones posteriores. Para personalizar cualquier proyecto definido en una colección para TFS 2018 o versiones anteriores, consulte Modelo de proceso XML local.

Reglas de flujo de trabajo

En la tabla siguiente se indican los tres grupos de reglas de flujo de trabajo que se pueden definir. El primer grupo aplica acciones estándar cuando se crea un elemento de trabajo, en un estado seleccionado o se mueve de un estado a otro. Estas acciones estándar establecen el valor de un campo o hacen que un campo sea de solo lectura o obligatorio. En este grupo, puede especificar una o dos condiciones y varias acciones.

Los grupos segundo y tercero admiten la restricción de las transiciones de estado. Estos dos grupos permiten especificar una y solo una condición que indica el estado al que se ha movido un elemento de trabajo. A continuación, puede especificar una o varias acciones para restringir la transición de ese estado a otros estados.

---

Condition

Acciones admitidas

---

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

---

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

---

Nota

A medida que personaliza un proceso heredado, todos los proyectos que usan ese proceso se actualizan automáticamente para reflejar las personalizaciones. Por este motivo, se recomienda crear un proceso de prueba y un proyecto de prueba cuando tenga una serie de personalizaciones para realizar con el fin de probar las personalizaciones antes de implementarlas en su organización. Para más información, consulte Creación y administración de procesos heredados.

Límites de estado y reglas de flujo 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 los estados de flujo de trabajo y las reglas, se recomienda tener en cuenta las instrucciones siguientes para minimizar los problemas de rendimiento.

• 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.
• Minimice el número de WIT personalizados que defina.

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 kanban o Panel de tareas, mover elemento de trabajo a 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

Definición de una regla

Antes de definir una regla basada en estados de flujo de trabajo, asegúrese de definir primero los siguientes elementos:

• El flujo de trabajo indica que desea, tal como se describe en Personalización de un flujo de trabajo.
• Si la regla requiere la especificación de un campo personalizado, agregue ese campo al tipo de elemento de trabajo, tal y como se describe en Agregar y administrar campos.
• Si la regla requiere la especificación de un grupo de seguridad para conceder o restringir los cambios en función de la pertenencia a usuarios o grupos, defina ese grupo de seguridad como se describe en Agregar o quitar usuarios o grupos, administrar grupos de seguridad.

Para conocer los conceptos básicos de la definición de reglas, consulte Adición de una regla personalizada. Debe cumplir los requisitos previos definidos en ese artículo.

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 la aprobación del responsable del equipo antes del trabajo activo

En este ejemplo, los equipos de desarrollo quieren asegurarse de que ningún caso de usuario funcione hasta que un responsable de equipo lo apruebe. Los estados de flujo de trabajo predeterminados están en uso y solo se agregan un único campo personalizado, Aprobado por y grupo de seguridad, Grupo de clientes potenciales de equipo.

Estados de flujo de trabajo predeterminados

Requisitos de reglas

Para garantizar la aprobación antes del trabajo activo, se deben definir las reglas siguientes:

• Requerir que el campo Aprobado por se rellene cuando el estado pase de Nuevo a Activo
• Restringir a los usuarios que no pertenecen al grupo de clientes potenciales del equipo para rellenar el campo Aprobado por
• Desactive el campo Aprobado por cuando el estado se mueva a Nuevo o Quitado

Definiciones de las reglas

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

   

---

Nombre de regla

Condition

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 requerido

Cuando A work item state changes from New to Active

Entonces Make required Approved By

---

Restringir 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

Al mantener la terminología utilizada por un grupo de negocios, se definen los siguientes estados de flujo de trabajo para el caso de usuario. Los estados heredados New, Resolved y Removed están ocultos. En su lugar, se usan los estados propuestos, revisados y cortados . Además, se definen tres Estados adicionales: Investigar, Diseñar y Aprobar. Estos Estados deben seguir la secuencia como se muestra en la imagen siguiente.

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 admitían las siguientes transiciones de estado hacia delante e inversa en el tipo de elemento de trabajo Caso de usuario.

• Propuesto solo puede moverse a Investigación y Corte
• La investigación solo puede moverse a Diseño y Cortar
• El diseño solo puede pasar a investigación, aprobado y cortado
• Aprobado solo puede pasar a Diseño, Activo y Cortar
• Activo solo puede moverse a En revisión
• En Revisión solo se puede mover a Activo (trabajo adicional encontrado), Cerrado o Cortado
• Cerrado puede pasar a investigación, diseño, activo, en revisión (permite casos en los que el usuario cerró el elemento de trabajo en caso de error).
• Cortar solo puede moverse a Propuesto.

Nota

Al restringir las transiciones de estado, tenga en cuenta los casos en los que un usuario mueve un estado en error. Quiere que los usuarios puedan recuperarse correctamente.

Además, el grupo de negocios quiere aplicar 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 que pertenecen al grupo Aprobadores autorizados rellenen el campo Aprobado por
• Desactive el campo Aprobado por cuando el estado se mueva a Cortar
• Requerir que los criterios de aceptación se rellenen cuando el estado se mueve a Activo

Definiciones de las reglas

Para implementar las restricciones anteriores, el administrador de procesos agrega un campo personalizado Aprobado por identidad, un grupo de seguridad Aprobadores autorizados y las once reglas siguientes.

   

---

Nombre de regla

Condition

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 la 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 definidas las reglas para el proceso y el proyecto actualizado con el proceso, actualice el explorador y compruebe las operaciones a través del formulario de elemento de trabajo y desde el explorador Kanban.

Para las reglas definidas en la tabla anterior, debería ver los siguientes menús desplegables Estado. Abra el panel Kanban y compruebe la capacidad de pasar de un estado a otro.

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

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

Al especificar una de las dos condiciones en función de la pertenencia a usuarios o grupos, 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.

Automatizar las transiciones de estado de los elementos de trabajo primarios

Para automatizar las transiciones de estado de los elementos de trabajo primarios en función de las asignaciones de estado realizadas a sus elementos de trabajo secundarios, puede agregar un webhook y usar el código y la configuración proporcionados en el proyecto Automate State Transitions de GitHub.

Nota

El proyecto Automate State Transitions de GitHub no es una característica compatible de Azure Boards y, por tanto, no es compatible con el equipo del producto. En el caso de preguntas, sugerencias o problemas que tiene al usar estas extensiones, hágalos en la página del proyecto de GitHub.

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

Anteriormente, el tipo de elemento de trabajo de error del proceso Agile tenía una regla que reasignaba el error a la persona que lo creó. Esta regla se ha quitado del proceso predeterminado del sistema. Puede restablecer la regla o agregar una regla similar a otros tipos de elementos de trabajo mediante la siguiente condición y acción:

CuandoA work item state changes toResuelto a continuaciónCopy the value from , creado porparaasignado.

Artículos relacionados

Nota:

Puede revisar los cambios realizados en un proceso heredado a través del registro de auditoría. Para más información, consulte Acceso, exportación y filtrado de registros de auditoría.

• Personalizar un flujo de trabajo
• Adición de una regla personalizada
• Almacenamiento en caché de formularios de elementos de trabajo