Validador de Dependencia entre Campos

El validador Field Dependency (Admin Essentials) bloquea una transición de workflow cuando un campo objetivo está vacío mientras otro campo (el disparador) tiene un valor determinado. Es la forma natural de modelar relaciones del tipo "si pasa A entonces B es obligatorio" sin tener que volver obligatorio el campo en todos los casos.

Un mismo validador puede contener varias reglas independientes, cada una con su propio par disparador → requerido y, opcionalmente, su propio mensaje de error.

¿Cuándo usar este validador?

• Cuando la prioridad es Highest, exigir que el campo Assignee esté informado antes de cerrar.
• Cuando el tipo de issue es Bug, exigir que se rellene un campo personalizado "Severidad" o "Pasos para reproducir".
• Cuando una Resolution concreta se elige (por ejemplo Won't Do), exigir un comentario explicativo.
• Cuando un select de "Origen del ticket" toma un valor concreto (ej. Cliente VIP), exigir un responsable de seguimiento.
• Cuando el campo Percentage supera un umbral (ej. >= 50), exigir que el campo Approver esté completado.
• Cuando el campo Email contiene un dominio corporativo, exigir un campo de seguimiento adicional.

A diferencia del validador Fields Required, donde un campo se exige siempre en la transición, este validador solo lo exige cuando se cumple la condición, evitando bloqueos innecesarios.

Añadir el validador a una transición

1. En Jira, abra la configuración del workflow que desea editar:

   • Para workflows asociados a un proyecto: Project settings → Workflows → Edit.
   • Para workflows globales: Jira settings → Issues → Workflows → Edit.

2. Seleccione la transición que quiere proteger.

3. Abra la pestaña Validators.

4. Haga clic en Add validator.

5. En la lista de validadores disponibles, seleccione Field Dependency (Admin Essentials) y haga clic en Add.

   

6. Defina una o más reglas (siguiente sección) y guarde.

7. Publique el workflow para que los cambios entren en vigor.

Configurar las reglas

Al añadir o editar el validador se abre su panel de configuración (una Custom UI servida por Forge). Cada regla se configura como una fila independiente. El formato de la regla varía según el tipo de campo disparador seleccionado:

• Modo selección: <campo disparador> is <valor> → then require <campo requerido>
• Modo numérico: <campo disparador> <operador> <umbral> → then require <campo requerido> (p. ej. Currency >= 10000)
• Modo color de banda: <campo disparador> is / is not <color> → then require <campo requerido> (p. ej. Traffic Light KPI is Rojo)
• Modo texto: <campo disparador> <operador> <valor> → then require <campo requerido> (p. ej. Email contains @empresa.com)

Y debajo, opcionalmente, un Error message específico para esa regla.

Tipos de campo disparador admitidos

Modo	Campos disponibles como disparador	Operadores	Control del valor
Selección	Priority, Issue Type, campos personalizados Single-select o Radio	is (igualdad exacta)	Lista de valores cargada automáticamente desde Jira
Numérico	Currency	=, !=, <, <=, >, >=	Campo de texto numérico libre
Color de banda	Traffic Light KPI, Percentage Field	=, !=, <, <=, >, >= · is, is not	Numérico libre · Selector Rojo / Amarillo / Verde
Texto	Email, Phone Number	equals, does not equal, contains, is empty, is not empty	Campo de texto libre (oculto para is empty / is not empty)

Modo numérico

Cuando el campo disparador es Currency, el validador muestra un selector de operador (=, !=, <, <=, >, >=) y un campo de texto para introducir el umbral numérico. La comparación se realiza sobre el valor almacenado del campo.

Ejemplo: Currency >= 10000 → then require Approver. Con esta regla, cualquier transición sobre un issue donde el campo Moneda valga 10 000 o más requerirá que el campo Aprobador esté relleno.

Modo color de banda

Desde la versión 5.0.0, cuando el campo disparador es Traffic Light KPI o Percentage Field, el validador muestra dos grupos de operadores:

• Operadores numéricos (=, !=, <, <=, >, >=) — comparan el valor numérico almacenado del campo, igual que en versiones anteriores.
• Operadores de color (is, is not) — comparan la banda de color del campo. Al seleccionar uno de estos operadores, aparece un selector con tres opciones: Rojo, Amarillo o Verde.

Al abrir el selector de valor, aparecen las tres opciones disponibles:

¿Qué ventaja tiene usar el color en vez del número?

Con los operadores de color no necesita conocer los umbrales numéricos configurados en cada contexto. La regla "si el semáforo está en rojo" funciona independientemente de los valores concretos de los umbrales, incluso si cambian en el futuro.

Semántica cuando la propiedad de color aún no existe en el issue:

• Con is: si el color no está persistido todavía, la regla no se activa — la transición puede ejecutarse.
• Con is not: si el color no está persistido todavía, la regla sí se activa — la transición se bloquea hasta que el campo tenga un valor guardado.

Los operadores de color leen la propiedad de issue que el complemento sincroniza automáticamente. Consulte Propiedades de banda de color para entender cómo funciona esa sincronización.

Modo texto

Cuando el campo disparador es de tipo texto (Email o Phone Number), el validador muestra un selector de operador de cadena. Para los operadores is empty e is not empty, el campo de valor se oculta automáticamente, ya que no requieren un valor de comparación.

Operadores disponibles:

• equals — coincidencia exacta con el valor introducido.
• does not equal — el campo no coincide exactamente con el valor.
• contains — el campo contiene la subcadena introducida.
• is empty — el campo está vacío (no requiere valor de comparación).
• is not empty — el campo tiene cualquier valor (no requiere valor de comparación).

Ejemplo: Email contains @empresa.com → then require Approver. Con esta regla, si el campo Email contiene el dominio corporativo, el campo Aprobador se vuelve obligatorio en la transición.

Campo requerido

El campo requerido puede ser cualquier campo del catálogo de Jira (sistema o personalizado), incluyendo Assignee, Comment, Description, Labels, Fix Versions, etc. El validador comprueba que el campo tenga un valor distinto de vacío en el momento de ejecutar la transición.

Mensaje de error personalizado

Cada regla puede llevar su propio Error message. Si lo deja en blanco, el complemento muestra un mensaje por defecto del estilo "Assignee is required when Priority is Highest.".

Múltiples reglas

Puede añadir tantas reglas como necesite haciendo clic en + Add rule. Cada regla se evalúa de forma independiente y todas las que se cumplan a la vez deben superarse para que la transición se ejecute (las reglas se combinan en AND).

Comportamiento en tiempo de transición

Cuando un usuario intenta ejecutar la transición:

• Si ninguna regla se dispara (es decir, ningún campo disparador cumple la condición configurada), la transición se ejecuta con normalidad.
• Si una o más reglas se disparan y sus campos requeridos correspondientes están vacíos, la transición se aborta y Jira muestra los mensajes de error de cada regla incumplida. El issue permanece en el estado anterior.

Combine con pantallas de transición

Como con cualquier validador, recomendamos asociar a la transición una pantalla que contenga los campos requeridos. Así el usuario puede completar los campos durante la transición en lugar de descubrir el error al final.

Compatibilidad con reglas configuradas en v3.0.0

Las reglas creadas con la versión 3.0.0 del validador (formato "v1": sin propiedad kind ni operator) siguen operativas sin necesidad de migración manual. Cuando el administrador abre el editor de reglas en la versión 3.1.0, las reglas antiguas se migran automáticamente al nuevo formato "v2" (se asigna operator = "equals" y kind = "select") sin perder la configuración existente. No es necesario reconfigurarlo todo desde cero.

Ejemplo: Assignee obligatorio cuando la prioridad es Highest

Suponga que el equipo desea garantizar que ningún issue de prioridad Highest avance a In Progress sin un responsable asignado.

1. Edite la transición "Start Progress" del workflow.
2. Añada el validador Field Dependency (Admin Essentials).
3. Configure la regla:
   • When field: Priority
   • is: Highest
   • then require: Assignee
4. (Opcional) Error message: "Asigne un responsable antes de iniciar un issue de prioridad Highest."
5. Guarde y publique el workflow.

A partir de ese momento:

• Un issue con prioridad Medium puede pasar a In Progress sin asignado.
• Un issue con prioridad Highest sin asignado se bloquea con el mensaje configurado.

Ejemplo: Comentario obligatorio según el tipo de issue

Si el equipo quiere que todos los Bugs lleven un comentario al pasar a Resolved:

1. Edite la transición "Resolve" del workflow.
2. Añada el validador Field Dependency (Admin Essentials).
3. Configure la regla:
   • When field: Issue Type
   • is: Bug
   • then require: Comment
4. (Opcional) Error message: "Para resolver un bug, registre un comentario explicativo del cierre."

Otros tipos de issue (Story, Task, etc.) pasan sin requerir comentario.

Ejemplo: Traffic Light KPI en rojo → Assignee obligatorio

Si el equipo quiere asegurarse de que ningún issue con el semáforo en rojo avance sin un responsable asignado:

1. Edite la transición que desea proteger (por ejemplo, "Submit for review").
2. Añada el validador Field Dependency (Admin Essentials).
3. Configure la regla:
   • When field: Traffic Light KPI (o el nombre del campo Semáforo en su instancia)
   • operador: is
   • valor: Rojo
   • then require: Assignee
4. (Opcional) Error message: "El semáforo está en rojo. Asigne un responsable antes de continuar."
5. Guarde y publique el workflow.

A partir de ese momento:

• Un issue con el semáforo en amarillo o verde puede avanzar sin asignado.
• Un issue cuyo semáforo está en rojo queda bloqueado hasta que se informe el campo Assignee.

No necesita conocer los umbrales

Esta regla funciona sin importar cuáles sean los umbrales numéricos configurados en el contexto del campo. Aunque el administrador cambie los límites de rojo en el futuro, la regla seguirá aplicando a los issues que estén en rojo según los nuevos umbrales, ya que compara el color — no el número.

Ejemplo: Porcentaje mayor o igual a 50 → Aprobador requerido

Si el proceso requiere aprobación formal cuando un indicador de avance llega al 50 % o más:

1. Edite la transición "Submit for approval" del workflow.
2. Añada el validador Field Dependency (Admin Essentials).
3. Configure la regla:
   • When field: Percentage (o el nombre del campo Porcentaje en su instancia)
   • operador: >=
   • umbral: 50
   • then require: Approver
4. (Opcional) Error message: "Cuando el avance es del 50 % o más, es necesario designar un aprobador antes de continuar."
5. Guarde y publique el workflow.

Con esta configuración, los issues con un valor de Porcentaje menor a 50 pueden avanzar sin aprobador, mientras que los que alcanzan o superan el 50 % quedan bloqueados hasta que se complete el campo.

Ejemplo: Email como condición para requerir un aprobador

Si los issues de contactos con dominio corporativo requieren un aprobador adicional:

1. Edite la transición "Escalate" del workflow.
2. Añada el validador Field Dependency (Admin Essentials).
3. Configure la regla:
   • When field: Email (o el nombre del campo Email personalizado)
   • operador: contains
   • valor: @empresa.com
   • then require: Approver
4. (Opcional) Error message: "Los contactos con email corporativo requieren un aprobador antes de escalar."
5. Guarde y publique el workflow.

Los issues con un Email que no contenga @empresa.com (o con el campo vacío) pasarán la transición sin requerir aprobador.

Número de teléfono vacío no bloquea

Si usa Phone Number como disparador con el operador is empty, recuerde que la regla solo se dispara cuando el campo está vacío. Si quiere que la transición se bloquee únicamente cuando el teléfono sí tiene un valor concreto, use equals o contains. El operador is empty e is not empty son especialmente útiles para exigir que un campo de texto esté o no esté relleno como condición previa a otra exigencia.

Diferencias frente a "Fields Required"

Aspecto	Fields Required	Field Dependency
Cuándo exige el campo	Siempre que se ejecute la transición	Solo cuando un campo disparador cumple la condición
Reglas por validador	Una sola lista de campos exigidos	Múltiples reglas (cada una con su par disparador → requerido)
Mensaje personalizado	Uno solo, global	Uno por regla
Caso típico	"Para esta transición, siempre exige Resolution"	"Para esta transición, exige Resolution sólo cuando el tipo es Bug"

Ambos validadores pueden coexistir en la misma transición. Si necesita una combinación, configure cada uno con su parte específica.