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
- 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
- Automatización del cierre de elementos de trabajo primarios
- Compatibilidad con un proceso de aprobación
- Realizar un campo requerido o de solo lectura u otro valor en función de los cambios de estado
- Automatización del cierre de elementos de trabajo primarios
Importante
El modelo de proceso de herencia está disponible para los proyectos configurados para admitirlo. Si usa una colección anterior, compruebe la compatibilidad del modelo de proceso. Si la colección local está configurada para usar el modelo de proceso XML local, solo puede usar ese modelo de proceso para personalizar la experiencia de seguimiento del trabajo. Para obtener más información, vea Elegir el modelo de proceso para la colección de proyectos.
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:
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.
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.
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.
En la tabla siguiente se describen los dos grupos de reglas de flujo de trabajo que puede definir:
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.
Restricción de las transiciones de estado:
- Especifique una condición que indique el estado del que se ha movido un elemento de trabajo.
- Defina una o varias acciones para restringir las transiciones de ese estado a otros estados.
Nota:
Algunas características requieren la instalación de la actualización de Azure DevOps Server 2020.1. Para más información, consulte notas de la versión de Azure DevOps Server 2020 Update 1 RC1, Boards.
Las condiciones y acciones de flujo de trabajo que puede establecer se muestran en las imágenes siguientes. Puede aplicar 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 necesario. Para este conjunto de reglas, puede especificar una o dos condiciones y varias acciones.
Condición
Acciones admitidas
Establecer el valor de campo o hacer que sea de solo lectura o necesario en función del estado
Restricción de una transición basada en el estado
Ocultar el campo o hacer que el campo sea de solo lectura o necesario en función del estado y la pertenencia a usuarios o grupos
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.
Nota:
Esta característica requiere la actualización 2020.1 de Azure DevOps Server o una versión posterior.
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.