Reglas y evaluación de reglas

Azure DevOps Services | | de Azure DevOps Server 2022 Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Las reglas se usan para establecer o restringir las asignaciones de valores a un campo de elemento de trabajo. Hay dos tipos principales de reglas, reglas generadas automáticamente y reglas personalizadas definidas para un proceso o proyecto. Las reglas generadas automáticamente minimizan la necesidad de agregar reglas personalizadas para las áreas que deben funcionar de forma estándar.

Las reglas personalizadas se definen para admitir los casos de uso empresariales. En función del tipo de datos de un campo, puede establecer varias restricciones sobre qué datos se pueden especificar en ese campo. Puede establecer los valores de una lista de selección (menú desplegable), establecer los valores predeterminados, borrar entradas o restringir los cambios. Con las reglas condicionales, puede aplicar reglas a un campo en función de las dependencias entre los valores de los distintos campos. También puede restringir quién puede modificar un campo o definir una regla para que solo se aplique a un grupo.

Lea este artículo para comprender lo siguiente:

  • Cómo aplica el sistema las reglas generadas automáticamente
  • Restricciones colocadas en la definición de reglas personalizadas en campos del sistema
  • Los diferentes tipos de reglas personalizadas que puede aplicar
  • Cómo se evalúan las reglas
  • Diferencia entre las reglas definidas para un proceso de herencia frente a un proceso XML local
  • Por qué debe minimizar el número de reglas personalizadas que defina

Antes de definir reglas personalizadas, lea Configurar y personalizar Azure Boards para comprender mejor cómo personalizar Azure Boards para satisfacer sus necesidades empresariales.

Sugerencia

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 reglas es demasiado compleja para que SQL se evalúe.

Reglas generadas automáticamente

Las reglas generadas automáticamente minimizan la necesidad de agregar reglas personalizadas para las áreas que deben funcionar de forma estándar.

Reglas de transición de estado

Los procesos heredados generan dinámicamente todo el conjunto de reglas de transición de estado a cualquier para cada tipo de elemento de trabajo personalizado y el estado personalizado agregado a un flujo de trabajo. Una transición de cualquier estado a cualquier estado es válida.

En el caso de los procesos XML locales, debe especificar las transiciones válidas dentro de la sección de la WORKFLOW definición de tipo de elemento de trabajo.

Transiciones de estado y reglas de campo Por/Fecha

Los campos By/Date corresponden a Created By/Date, Activated By/Date, Resolved By/Date y Closed By/Date.

En el caso de los procesos heredados, estos campos se establecen o borran automáticamente al realizar la transición de un elemento de trabajo de un estado a otro. Los campos Modificados por/Fecha no se incluyen, ya que se actualizan con cada elemento de trabajo guardado y no están relacionados con las transiciones de estado.

Las reglas y comportamientos predeterminados que rigen estos campos incluyen:

  1. El estado Closed siempre se encuentra en la categoría Estado completado .
  2. La categoría estado Completado no es configurable y está asociada a uno y solo a un Estado.
  3. Este estado Closed siempre está cerrado para los procesos Agile y CMMI, y siempre listo para los procesos Scrum y Basic.
  4. La generación automática de estas reglas se ve afectada por la configuración regional, ya que la condición de regla contiene el nombre de estado, que se localiza. El sistema genera reglas diferentes para distintas configuraciones regionales.
  5. Las reglas generadas automáticamente para estos campos solo se especifican para los tipos de elementos de trabajo que incluyen estos campos. Es posible que un tipo de elemento de trabajo no incluya uno o varios de estos campos.
  6. Estas reglas son necesarias cuando un tipo de elemento de trabajo tiene estados personalizados o el tipo de elemento de trabajo es un tipo de elemento de trabajo personalizado.
  7. Estas reglas solo se aplican a los procesos heredados; nunca se generan para los procesos XML hospedados o XML locales.

Los estados de flujo de trabajo están asociados a categorías de estado para admitir el flujo de trabajo en paneles Kanban. Para más información, consulte Cómo se usan los estados de flujo de trabajo y las categorías de estado en Trabajos pendientes y paneles.

Reglas de campo De fecha de cambio de estado

Estas reglas son técnicamente mucho más sencillas que las reglas Cerradas por fecha cerrada porque no dependen de ningún estado determinado. Para cualquier tipo de elemento de trabajo, siempre funcionarán las mismas reglas. Deben generarse automáticamente porque algunos tipos de elementos de trabajo OOB no contienen el campo Fecha de cambio de estado, por lo que cuando el usuario agrega este campo a un tipo de elemento de trabajo personalizado, estas reglas también deben generarse automáticamente. También se aplican los mismos principios para las reglas cerradas por fecha cerrada aquí.

Reglas personalizadas

Todas las reglas personalizadas son opcionales. Para un proceso heredado, especifique una regla que consta de una condición más una acción. Para un proceso XML local, especifique reglas para un campo o dentro del flujo de trabajo.

No hay una asignación uno a uno entre los dos procesos. En algunos casos, la regla de elementos XML se define dentro del cuadro de diálogo Editar campo para el proceso heredado y no como regla. Otros elementos XML, como FROZEN, MATCH, NOTSAMEAS, , no se admiten en el proceso heredado.

Tenga en cuenta lo siguiente:

  • Las reglas siempre se aplican, no solo cuando se interactúa con el formulario, sino también al interactuar con otras herramientas. Por ejemplo, establecer un campo como de solo lectura no solo aplica la regla en el formulario de elemento de trabajo, sino también a través de la API y excel Azure DevOps Server complemento.
  • Las entradas de proceso heredadas especifican condiciones y acciones para realizar una regla completa. Los elementos XML no hacen esas diferencias.
  • Las reglas de campo no admiten la asignación de valores que son la suma de otros dos campos o que realizan otros cálculos matemáticos. Sin embargo, puede encontrar una solución que se adapte a sus necesidades a través de la extensión de Marketplace del agregador de TFS (servicio web). Consulte también Acumulación de trabajo y otros campos.
  • Puede encontrar soluciones adicionales para aplicar reglas personalizadas a campos mediante extensiones de Marketplace, como la extensión biblioteca de control de formularios del elemento de trabajo.

Composición de reglas

Para un proceso heredado, cada regla consta de dos partes: Condiciones y acciones. Las condiciones definen las circunstancias que se deben cumplir para que se aplique la regla. Las acciones definen las operaciones que se van a realizar. Para la mayoría de las reglas, puede especificar un máximo de dos condiciones y 10 acciones por regla. Todas las reglas personalizadas requieren que se cumplan todas las condiciones para poder ejecutarse.

Por ejemplo, puede hacer que un campo sea necesario en función del valor asignado al estado y a otro campo. Por ejemplo:

   (Condition) When a work item State isActivo
   (Condition) And when the value ofÁrea de valor = Negocio
   (Action) Then make requiredPuntos de historia

Nota

Actualmente, solo se admite una condición para las reglas de transición de estado. Si va a aplicar reglas basadas en el estado, consulte Aplicar reglas a estados de flujo de trabajo.

En la tabla siguiente se resumen las acciones que están disponibles con las condiciones seleccionadas.

Condition

Acciones admitidas

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

Condiciones, se crea un elemento de trabajo

Acciones, se crea un elemento de trabajo

Restringir una transición basada en el estado

Condición, se mueve el elemento de trabajo

Acciones, restrinja una transacción en función del estado.

Ocultar campo o hacer que el campo sea de solo lectura o obligatorio en función del estado y la pertenencia a usuarios o grupos

Condición, pertenencia a grupos de usuarios

Acciones, restrinja una transacción en función del estado y la pertenencia.

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

Condición, pertenencia a grupos de usuarios

Acciones, restrinja una transacción en función del estado y la pertenencia.

¿Qué ocurre si se definen demasiadas reglas?

Se define una sola expresión SQL por proyecto para validar los elementos de trabajo cada vez que se crean o actualizan. Esta expresión crece con el número de reglas que se especifican para todos los tipos de elementos de trabajo definidos para el proyecto. Cada calificador de comportamiento especificado para un campo da como resultado un aumento en el número de subexpresiones. Las reglas anidadas, las reglas que se aplican solo en una transición o condicionadas en el valor de algún otro campo, hacen que se agreguen más condiciones a una IF instrucción . Una vez que la expresión alcanza un determinado tamaño o complejidad, SQL no puede evaluarla más y genera un error. La eliminación de algunas WIT o la eliminación de algunas reglas puede resolver el error.

Puede establecer los valores de una lista de selección (menú desplegable), establecer los valores predeterminados, borrar entradas o restringir los cambios. Con las reglas condicionales, puede aplicar reglas a un campo en función de las dependencias entre los valores de los distintos campos. También puede restringir quién puede modificar un campo o definir una regla para que solo se aplique a un grupo.

Las reglas de elementos de trabajo no existen como una sola colección. Las reglas se generan y combinan dinámicamente a partir de orígenes de datos diferentes. La lógica de combinación es una sencilla, consolida reglas idénticas, pero no recorta las reglas en conflicto.

Omitir reglas

En general, el motor de reglas valida todos los elementos de trabajo cuando los usuarios modifican el elemento de trabajo. Sin embargo, para admitir determinados escenarios, los usuarios asignados a las reglas de omisión en el permiso de nivel de proyecto de actualizaciones de elementos de trabajo pueden guardar elementos de trabajo sin que se evalúen las reglas.

Las reglas se pueden omitir de dos maneras. La primera es a través de la API REST Elementos de trabajo: actualice y establezca el bypassRules parámetro en true. El segundo es a través del modelo de objetos de cliente, inicializando en modo bypassrules (inicializar WorkItemStore con WorkItemStoreFlags.BypassRules).

Campos del sistema y reglas personalizadas

Los campos del sistema tienen Sistema. Nombres de referencia, por ejemplo System.Title y System.State.

Los siguientes campos del sistema son necesarios para tener un valor: Id. de área, Fecha de cambio, Fecha de creación, Creado por, Estado y Motivo.

El motor de reglas restringe la configuración de condiciones o acciones a campos del sistema, excepto lo siguiente:

  • Puede hacer que los campos Estado y Motivo sean de solo lectura.
  • Puede aplicar la mayoría de las reglas a los campos Título, Asignado a, Descripción y Cambiado por .

Si no ve un campo que aparece en el menú desplegable de la interfaz de usuario de la regla para el proceso de herencia, este es el motivo. Por ejemplo, si intenta convertir la ruta de acceso del área (System.AreaPath) en función de una condición, el campo Ruta de acceso del área no está disponible para la selección. Incluso si puede especificar un campo del sistema, el motor de reglas puede impedir que guarde la regla.

Reglas predeterminadas y de copia

Las reglas predeterminadas y de copia modifican los valores de los campos de elementos de trabajo. Definen restricciones y comportamiento en tiempo de ejecución, como especificar valores predeterminados, borrar campos, requerir que se definan los campos, etc.

Puede restringir la aplicación de estas reglas en función de la pertenencia a grupos del usuario actual, tal como se describe en Restricciones de reglas de pertenencia a grupos o usuarios.

La mayoría de estas acciones de regla se pueden aplicar con la selección de cualquier condición.

Acción de proceso heredado

Descripción

Copy the value from...

Especifica otro campo que contiene un valor que se va a copiar en el campo actual.

Clear the value of...

Borra el campo de cualquier valor que contenga.

Use the current time to set the value of ...

Establece la hora de un campo en función de la configuración de hora del usuario actual.

Reglas de restricción

Las reglas de restricción restringen el cambio del valor de un campo. Definen los estados válidos para un elemento de trabajo. Cada restricción funciona en un único campo. Las restricciones se evalúan en el servidor en el guardado del elemento de trabajo y, si se infringe alguna restricción, se rechaza la operación de guardado.

Puede restringir la aplicación de estas reglas en función de la pertenencia a grupos del usuario actual, tal como se describe en Restricciones de reglas de pertenencia a grupos o usuarios.

La mayoría de estas acciones de regla se pueden aplicar con la selección de cualquier condición.

Acción de proceso heredado

Descripción

Hide the field...
Solo está disponible cuando se selecciona una condición de pertenencia a grupos.

Especifica que no se muestra el campo en el formulario de elemento de trabajo, lo que básicamente quita la capacidad para que el usuario actual cambie el valor del campo.

Make read-only

Evita que un campo se modifique en modo alguno. Tal vez desee aplicar esta regla en determinadas condiciones. Por ejemplo, después de cerrar un elemento de trabajo, desea hacer que un campo sea de solo lectura para conservar los datos con la finalidad de generar informes.
Para especificar que el campo predeterminado es de solo lectura, especifique en el cuadro de diálogo Editar campo, pestaña Opciones .

Make required

Requiere que un usuario especifique un valor para el campo. Los usuarios no pueden guardar un elemento de trabajo hasta que tengan valores asignados en todos los campos requeridos.
Para especificar el valor predeterminado del campo, especifique en el cuadro de diálogo Editar campo, pestaña Opciones .

Seleccionar listas

Las listas de selección definen los valores que un usuario puede o no puede elegir para un campo String o Integer. Los valores definidos en una lista de selección aparecen en un formulario de elemento de trabajo y en el editor de consultas.

Para un proceso heredado, las listas de selección se definen mediante el cuadro de diálogo Editar campo.

Cuadro de diálogo Editar campo

Descripción

Pestaña Definición de un campo de lista de selección

Define una lista de valores permitidos para el campo. Los valores permitidos son valores disponibles para seleccionarlos en una lista de campos en los formularios de elementos de trabajo y en el generador de consultas. Debe seleccionar uno de estos valores.

Active la casilla Permitir que los usuarios escriban sus propios valores en la pestaña Opciones para permitir que los usuarios especifiquen sus propias entradas.

Define una lista de valores sugeridos para el campo. Los valores sugeridos son los valores que están disponibles para seleccionarlos en una lista de campos en los formularios de elementos de trabajo y en el generador de consultas. Además de los valores que figuran en la lista, puede agregar otros.

Cambios o valores de campo condicionales

Las reglas condicionales especifican una acción basada en el valor de un campo que es igual o no a un valor específico, o si se realizó un cambio o no en el valor de un campo específico. En general, las reglas condicionales se aplican primero sobre las reglas incondicionales. Cuando varias reglas condicionales se evalúan como true, el orden de ejecución es: When, WhenNot, WhenChanged, WhenNotChanged.

Puede especificar varias reglas condicionales por campo. Sin embargo, solo puede especificar un único campo esencial por regla condicional.

Condición heredada

Descripción

The value of ... (equals) [Cuándo]

Especifica una o más reglas que se aplicarán al campo actual cuando otro campo tenga un valor concreto.

A change was made to the value of ... [WhenChanged]

Aplica una o más reglas al campo actual cuando se cambia el valor de un campo concreto.

The value of ... (not equals) [WhenNot]

Aplica una o más reglas al campo actual cuando otro campo no tiene un valor concreto.

No change was made to the value of ... [WhenNotChanged]

Aplica una o más reglas al campo actual cuando no se cambia el valor de un campo concreto.


Acción heredada

Descripción

Clear the value of ...
Copy the value from ...
Make read-only ...
Make required ...
Set the value of ...
Use the current time to set the value of ...
Use the current user to set the value of ...

Especifica la acción que se va a realizar en un campo específico.

Restricciones de reglas de pertenencia a grupos o usuarios

Puede restringir la aplicación de una regla en función de la pertenencia del usuario actual. Se recomienda limitar el ámbito de la regla a un grupo de seguridad de Azure DevOps y no a un solo usuario, aunque puede especificar esta última. Para que la regla tenga el ámbito de varios grupos, debe crear un grupo primario de Azure DevOps que incluya el conjunto de grupos que desea usar.

Implementación de procesos

Sugerencia

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

Como se indica en la tabla siguiente, para restringir una regla basada en la pertenencia del usuario actual, especifique una de las dos condiciones para un proceso heredado. Estas reglas están activas para Azure DevOps 2020 y versiones posteriores.

Se aplica a

Regla

Condición

Current user is a member of group ...
Current user is not member of group ...

Acción

Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...

Uso de tokens para hacer referencia a usuarios o grupos

Los campos de identidad o selector de personas pueden aceptar valores que hacen referencia a usuarios y grupos. Al restringir una regla a un grupo, se indica el dominio o el ámbito del grupo. Para algunos valores, puede utilizar tokens.

Entre los ejemplos de tokens se incluyen los siguientes:

  • [ProjectName], como [Fabrikam], [FabrikamFiber], [MyProject]
  • [OrganizationName], como [fabrikam], [myorganization]
  • [CollectionName], como [fabrikam], [myorganization]

Para obtener información sobre los ámbitos disponibles para el proyecto u organización, vaya a la página Grupos de permisos>de configuración> del proyecto u Grupos de permisos>de configuración> de la organización, puede filtrar la lista según sea necesario. Por ejemplo, en la imagen siguiente se muestran las cuatro primeras entradas en una lista filtrada basada en Azure DevOps. Para más información, consulte Cambio de permisos de nivel de proyecto o Cambio de permisos de nivel de colección de proyectos.

Captura de pantalla de la lista de grupos de permisos filtrados.

Para más información sobre los grupos de seguridad predeterminados, consulte Permisos y grupos.

Evaluación de la regla de acceso

Las reglas que especifican una condición basada en la pertenencia de usuario o grupo del usuario que modifica un elemento de trabajo se evalúan de dos maneras. Cuando se evalúa la regla, la aplicación debe determinar si la regla se aplica al usuario actual comprobando si ese usuario es o no miembro del grupo especificado.

  • Al modificar el elemento de trabajo desde el portal web, la API REST o el comando azure boards , se realiza una solicitud a Azure Active Directory o Active Directory. No se producen problemas para esta operación.
  • Al modificar el elemento de trabajo de Visual Studio, Team Explorer Everywhere, Excel u otra herramienta personalizada mediante el modelo de objetos de cliente WIT, la solicitud para evaluar la pertenencia se basa en una memoria caché de cliente. La caché de cliente no es consciente de los grupos de Active Directory.

Nota

Visual Studio 2019 Team Explorer para proyectos que usan GIT se ha vuelto a escribir para usar las API REST.

Para evitar problemas con los usuarios que actualizan elementos de trabajo de varios clientes, especifique grupos de seguridad de Azure DevOps en lugar de grupos de Active Directory. Puede crear fácilmente un grupo de seguridad de Azure DevOps para que se corresponda con un grupo de Active Directory. Para obtener información sobre cómo hacerlo, consulte Adición o eliminación de usuarios o grupos, administración de grupos de seguridad.

Nota

El OM del cliente WIT está en desuso. A partir del 1 de enero de 2020, ya no se admite cuando se trabaja con Azure DevOps Services y Azure DevOps Server 2020.

Orden en el que se evalúan las reglas

Las reglas normalmente se procesan en la secuencia en la que están presentes. Sin embargo, la secuencia completa para la evaluación de todas las reglas no es totalmente determinista.

En esta sección se describen el comportamiento esperado y las interacciones al aplicar reglas condicionales, de copia y predeterminadas.

Los pasos siguientes muestran, en la secuencia correcta, las interacciones que realiza Azure DevOps y por el usuario de un formulario de elemento de trabajo. El usuario solo realiza los pasos 1, 8 y 13.

  1. Desde un cliente de Azure DevOps, como el portal web, Visual Studio/Team Explorer o Team Explorer Everywhere, un usuario crea un nuevo elemento de trabajo o edita un elemento de trabajo existente.

  2. Rellene los campos predeterminados. Para todos los campos, aplique los valores predeterminados asignados al campo que no formen parte de una cláusula condicional.

  3. Copie o establezca valores de campo. Para todos los campos, aplique las reglas para copiar un valor o establecer el valor de un campo que no forme parte de una cláusula condicional.

  4. Para todos los campos con una regla condicional When que coincida, aplique reglas para establecer o copiar un valor de campo.

  5. Para todos los campos con una regla condicional When Not que coincida, aplique reglas para establecer o copiar un valor de campo.

    El sistema siempre procesa las reglas When before When Not .

  6. Para todos los campos que han cambiado sus valores desde el paso 1 y que contienen reglas When Changed , aplique reglas para establecer o copiar un valor de campo.

  7. Permita que el usuario empiece a editar.

  8. El usuario modifica un valor de campo y después quita el foco del campo.

  9. Procese las reglas When para ese campo que coincidan con el nuevo valor.

  10. Procese las reglas When Not para ese campo que coincidan con el nuevo valor.

  11. Procese las reglas When Changed para ese campo que coincidan con el nuevo valor.

  12. Permita que el usuario vuelva a editar.

  13. El usuario guarda los cambios en el almacén de datos.

  14. Para todos los campos, aplique las Use the current time to set the value of ... acciones definidas para el campo directa o indirectamente bajo una regla condicional.