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, es posible que desee definir una o varias reglas que se apliquen 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 para admitir 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
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
- Restricción de las transiciones de estado
- Restringir o permitir transiciones de estado a usuarios o grupos específicos
- Automatización de las transiciones de estado de los elementos de trabajo primarios
- 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
- Restricción de las transiciones de estado
- Automatización de las transiciones de estado de los elementos de trabajo primarios
- 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
- Automatización de las transiciones de estado de los 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.
Reglas de flujo de trabajo
En la tabla siguiente se indican los tres grupos de reglas de flujo de trabajo que puede 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 necesario. 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.
En la tabla siguiente se indican los dos grupos de reglas de flujo de trabajo que puede 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 necesario. En este grupo, puede especificar una o dos condiciones y varias acciones.
El segundo grupo admite la restricción de las transiciones de estado. En este segundo grupo, puede especificar una y solo una condición que indique 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.
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.
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 tipos de elementos de trabajo personalizados.
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
Definición de una regla
Antes de definir una regla basada en estados de flujo de trabajo, defina los siguientes elementos:
- Los estados de flujo de trabajo que desea, tal y 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 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, administre 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 aprobación de responsable de equipo antes del trabajo activo
En este ejemplo, los equipos de desarrollo quieren asegurarse de que ningún artículo de usuario funcione hasta que un responsable del equipo lo apruebe. Los estados de flujo de trabajo predeterminados están en uso y solo se agrega 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, defina 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 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 de negocios decidió establecer reglas que admitan las siguientes transiciones de estado hacia delante e inverso 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 Corte
- El diseño solo puede moverse a Investigación, Aprobado y Cortado
- Aprobado solo puede pasar a Diseño, Activo y Corte
- Activo solo se puede mover a En revisión
- En Revisión solo se puede mover a Activo (Se encontró más trabajo), 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 error)
- Cortar solo puede moverse a Propuesta.
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 mueve 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 siguientes 11 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 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.
Para las reglas definidas en la tabla anterior, debería ver los siguientes menús desplegables Estado. Abra la placa y compruebe la capacidad de 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 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.
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 en función de las asignaciones de estado de sus elementos de trabajo secundarios, consulte Automatización de las 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
Nota:
Revise los cambios realizados en un proceso heredado a través del registro de auditoría. Para obtener más información, consulte Acceso, exportación y filtrado de registros de auditoría.