Ir al contenido

Alertas de filtro

Una alerta de filtro vigila todo un conjunto de tickets en lugar de uno solo. El ámbito se define con una consulta JQL o con un filtro guardado de Jira: «cualquier ticket del proyecto X», «todos los bugs críticos», «cada solicitud de mi cola».

Las alertas de filtro se crean en la página de resumen de HeadsUp: Apps → HeadsUp → + Nueva alerta de filtro.

Diálogo Nueva alerta de filtro con un filtro guardado elegido y el campo JQL relleno

  1. Elige el ámbito. Lo más sencillo es la lista «Usar un filtro guardado (opcional)»: muestra tus filtros de Jira y copia su JQL, que sigue siendo editable. También puedes escribir la JQL directamente, se valida al guardar.
  2. Elige el disparador:
    • Aparece un ticket nuevo en el filtro, por ejemplo cada bug nuevo del proyecto X
    • Cambio de estado (cualquiera o uno objetivo), nuevo comentario, cambio de prioridad, cambio del responsable
    • La IA detecta …, una condición en lenguaje natural evaluada en todos los tickets del filtro, ver Detección de IA
    • SLA próximo a incumplirse, ver más abajo
  3. Ponle un nombre si quieres. El nombre aparece entre corchetes en el asunto del correo, así se ve de un vistazo de dónde viene el aviso.

Las alertas de filtro siguen activas permanentemente hasta que se borran.

Las alertas de filtro funcionan siempre de forma permanente, así que pueden tener fecha de caducidad. El campo Caduca ofrece Sin caducidad, En 2 semanas, En 1 mes, En 3 meses, En 6 meses o una fecha concreta. Sin caducidad viene preseleccionado.

Esto importa sobre todo en la detección de IA: una alerta olvidada sigue consumiendo los créditos de IA compartidos del sitio. Una fecha de caducidad lo termina sin que nadie tenga que acordarse.

Siete días antes de la fecha recibes un aviso para poder ampliarla. Una alerta caducada queda pausada, no borrada, y un clic la devuelve a la vida.

Para Jira Service Management, una alerta de filtro puede avisar antes de que se incumpla un SLA: elige el disparador «SLA próximo a incumplirse» y un umbral (1, 2, 4, 8 o 24 horas). HeadsUp revisa las solicitudes abiertas cada hora y avisa de cada solicitud exactamente una vez por alerta, así que un incumplimiento cercano no se convierte en spam horario. En cada pasada, una alerta revisa las primeras 50 solicitudes abiertas de su filtro. Una cola con más solicitudes abiertas conviene repartirla en varias alertas, por ejemplo por proyecto o por prioridad.

Este disparador forma parte de la edición Advanced. En la edición Standard no aparece en la lista de disparadores.

Dos casos se quedan callados a propósito. Un SLA pausado no envía aviso, porque el reloj no corre mientras la solicitud espera al cliente, y el aviso llegará igualmente al reanudarse. Un incumplimiento que ya ha ocurrido tampoco envía aviso, porque un aviso anticipado a posteriori no lo es.

Lista de disparadores con SLA próximo a incumplirse y los umbrales abiertos

Debajo de cada alerta de filtro de la página de resumen está también Mostrar registro. Desplegado muestra qué ha hecho la alerta: se ha activado y se ha entregado, la IA la ha evaluado, o bien Jira ha rechazado la JQL o no se han podido leer los datos del SLA. Las entradas se cargan al desplegarlo por primera vez. La lista de entradas posibles está en Notificaciones y bandeja de entrada.

Una alerta de filtro no se puede editar. En la página de resumen solo aparece Eliminar, y el servidor también rechaza cualquier cambio. Para cambiar la JQL, el disparador o el nombre, borra la alerta y créala de nuevo; la JQL de un filtro guardado es de todos modos una copia fija. Con los recordatorios de tickets es distinto, se pueden editar tanto en el panel del ticket como en la página de resumen.

Las alertas de filtro por evento (estado, comentario, prioridad, responsable, ticket nuevo) reaccionan en segundos. La comprobación de SLA se ejecuta cada hora: un aviso puede llegar hasta una hora después de que el tiempo restante baje del umbral.