Escenarios de reglas personalizadas de ejemplo

  • Artículo

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

En este artículo se proporcionan ejemplos de definiciones de reglas personalizadas. Todas las reglas personalizadas se definen para un tipo de elemento de trabajo. Se proporcionan ejemplos para los modelos de proceso XML heredados y locales.

Antes de agregar reglas personalizadas, lea Reglas y evaluación de reglas y Agregar una regla a un tipo de elemento de trabajo (proceso de herencia).

Definir un campo obligatorio dependiente

Puede especificar que un campo solo es necesario cuando otro campo contiene un valor específico. En el ejemplo siguiente, cuando un cliente notifica un problema, el campo Customer Reported personalizado se establece en True y el campo Gravedad se requiere. Si un cliente no notifica el problema, no es necesario un valor para el campo Gravedad .

Captura de pantalla de la regla personalizada para que la gravedad sea necesaria cuando customer REported field=true.

Borrar el valor de un campo dependiente

En el ejemplo siguiente se muestra cómo definir una regla personalizada para borrar el valor de Puntos de historia cuando se realiza un cambio en la fecha de inicio.

Captura de pantalla de la regla personalizada para borrar el valor de Puntos de historia cuando cambia la fecha de inicio.

Establecer un valor de campo dependiente

En los ejemplos siguientes se muestra cómo asignar los valores del campo Tamaño en función del valor seleccionado para el campo personalizado, campo Tamaño de camiseta.

La lista de selección Tamaño de camiseta consta de cuatro valores Small, Medium, Large y X-Large. Se definen cuatro reglas personalizadas para asignar el campo Tamaño cuando se cambia el campo Tamaño de camiseta a un valor específico. Para simplificar el uso, el valor predeterminado del tamaño de camiseta es Pequeño.

Cuadro de diálogo Editar campo para el campo Tamaño de camiseta

Captura de pantalla del cuadro de diálogo Editar campo para el campo Tamaño de camiseta.

Regla personalizada

Captura de pantalla de la regla personalizada para establecer el valor tamaño de tamaño cuando tamaño de camiseta está establecido en Pequeño.

Cuatro reglas personalizadas

Captura de pantalla de cuatro reglas personalizadas para establecer el valor tamaño cuando se establece el tamaño de la camiseta.

Requerir un valor de campo tras los cambios de estado

En el ejemplo siguiente se muestra cómo puede requerir la especificación del campo Trabajo restante cuando el estado del flujo de trabajo de la tarea cambia a Activo.

Captura de pantalla de la regla personalizada para que el trabajo restante sea necesario cuando se cambia el estado a Activo.

Borrar el valor de un campo al cerrar el estado

Para automatizar la desactivación del campo Trabajo restante al cerrar una tarea, defina una regla personalizada como se indica.

Captura de pantalla de la regla personalizada a cero fuera Trabajo restante necesario cuando se cambia el estado a Cerrado.

Restringir la creación de elementos de trabajo por un grupo

Una regla personalizada que restringe la transición a la categoría estado Propuesto de un tipo de elemento de trabajo impide eficazmente la creación de elementos de trabajo de ese tipo. Al aplicar la regla a un grupo específico, se impide eficazmente que ese grupo cree elementos de trabajo de ese tipo.

La siguiente regla personalizada restringe a un equipo de proyecto la creación de elementos de trabajo a medida que la categoría Estado propuesto se asigna al estado Nuevo flujo de trabajo.

Captura de pantalla de una regla personalizada para restringir la creación de un elemento de trabajo por un grupo.

Restringir la modificación de elementos de trabajo por un grupo

Para un proceso de herencia, puede impedir que los usuarios modifiquen un elemento de trabajo estableciendo el permiso de denegación para un grupo en una ruta de acceso de área. En el caso de un proceso XML local, puede establecer restricciones en cada estado de flujo de trabajo de un grupo que les impida guardar el elemento de trabajo en cualquier estado.

No es posible definir una regla personalizada que restrinja la modificación de elementos de trabajo de un tipo específico. Solo puede especificar la restricción por estado. Si el usuario no cambia el estado, puede modificar otros campos, a menos que todos los campos se hagan de solo lectura para el grupo.

En su lugar, si desea restringir un grupo de usuarios de modificar los elementos de trabajo seleccionados de cualquier tipo, puede asignar esos elementos de trabajo a una ruta de acceso de área. Defina un grupo de seguridad y, a continuación, establezca restricciones para editar elementos de trabajo para esa ruta de acceso de área para ese grupo, como se muestra en la siguiente imagen. Para más información, consulte Establecimiento de permisos y acceso para el seguimiento del trabajo, Creación de nodos secundarios y modificación de elementos de trabajo en una ruta de acceso de área.

Captura de pantalla del cuadro de diálogo Permisos de una ruta de acceso de área para restringir las modificaciones de los elementos de trabajo.

Restricción de las transiciones de estado

En el caso de los procesos heredados, las transiciones de estado cualquiera a cualquier se definen automáticamente. Esto permite a los usuarios avanzar en el estado de flujo de trabajo de nuevo a completado, pero también para retroceder en caso de que sea necesario. Al definir reglas personalizadas para restringir una transición, tenga en cuenta que si un usuario comete un error al actualizar el flujo de trabajo, es posible que no pueda corregirlo. Por ejemplo, podrían actualizar el estado moviendo una tarjeta de elemento de trabajo a una fase posterior en el panel Kanban, pero no volver a moverla.

Sugerencia

Considere la posibilidad de restringir una transición de estado para algunos, pero no para todos los usuarios. De este modo, si un usuario comete un error, puede pedir a otro miembro del equipo que restablezca el valor de Estado para omitir la restricción.

Antes de definir reglas de transición de estado, revise Reglas y evaluación de reglas, reglas generadas automáticamente y Cómo se usan los estados de flujo de trabajo y las categorías de estado en Trabajos pendientes y paneles.

Restricción de la modificación de elementos de trabajo cerrados

En función de los procesos empresariales, puede impedir que los usuarios sigan modificando o actualizando los elementos de trabajo que se han cerrado o completado. Puede agregar reglas a los tipos de elementos de trabajo para evitar que los usuarios vuelvan a abrir elementos de trabajo cerrados.

Para el proceso heredado, puede agregar una regla que restrinja la transición de estado. Por ejemplo, la siguiente regla restringe la transición de cerrada a los otros dos Estados, Nuevo y Activo.

Nota:

La A work item state moved from ... condición está disponible para Azure DevOps Server 2020 y versiones posteriores.

Regla personalizada, el usuario actual no es miembro de un grupo, no permite las transiciones al estado Nuevo o Activo desde Cerrado

Nota:

En función de la acción de regla que especifique, puede deshabilitarse el botón Guardar del formulario de elemento de trabajo o se muestra un mensaje de error cuando un usuario restringido intenta modificar el elemento de trabajo.

Ocultar o restringir la modificación de un campo en base a un usuario o grupo

Al seleccionar o Current user is a member of group...Current user is not a member of group..., puede ocultar un campo, hacer que un campo sea de solo lectura o hacer necesario un campo.

Por ejemplo, la siguiente condición indica que el campo Justificación está oculto para los miembros que no pertenecen al grupo Fabrikam Fiber\Voice.

Regla personalizada, el usuario actual no es miembro de un grupo, campo Ocultar justificació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.

Restringir la modificación de un campo seleccionado en base a un usuario o grupo

Puede personalizar los tipos de elementos de trabajo para restringir quién puede modificar un campo específico para un tipo de elemento de trabajo.

Nota:

Para Azure DevOps Server 2019 y versiones anteriores, solo puede restringir la modificación de elementos de trabajo en función de un usuario o grupo con el modelo de proceso XML local.

Con una de las dos condiciones siguientes, puede hacer que los campos seleccionados sean necesarios para un usuario de un grupo de seguridad o que no sean miembros de un grupo de seguridad.

  • current user is a member of a group...
  • current user is not a member of a group...

Sugerencia

Para evitar problemas de evaluación de reglas que pueden surgir, especifique los grupos de seguridad de Azure DevOps y no el identificador de Microsoft Entra o los grupos de seguridad de Active Directory. Para más información, consulte Reglas predeterminadas y el motor de reglas.

Por ejemplo, puede hacer que los campos Título o Estado Sean de solo lectura para usuarios o grupos seleccionados.

Por ejemplo, el campo Prioridad , para el tipo de elemento de trabajo User Story, se convierte en de solo lectura para los miembros del grupo Fabrikam Fiber\Voice. Cuando un usuario de este grupo abre un caso de usuario, no puede cambiar el valor en el campo Prioridad.

Regla personalizada, el usuario actual no es miembro de un grupo, hacer que el campo Prioridad sea de solo lectura.