Generar informes HTML

Los comandos ajat report convierten una instantánea de exportación en un único archivo HTML autocontenido que puedes abrir sin conexión, adjuntar a un ticket o archivar como evidencia de cumplimiento. Hay cinco informes, cada uno una lente distinta sobre el estado de la automatización. Elige el que responda tu pregunta.

Cada informe lee el catálogo JSON local en disco — no se realiza ninguna llamada en vivo a Jira. Eso significa que puedes generar, revisar y compartir informes sin credenciales y sin tocar el tenant.

Los cinco informes

Cada informe trae su propia paleta de acento para reconocerlo de un vistazo. Los cinco comparten la misma interfaz de navegación — búsqueda del lado del cliente, secciones plegables, tablas ordenables, temas claro/oscuro, un botón de impresión y enlaces a Jira cuando la instantánea capturó el sitio: cada regla abre en su propia página, y los proyectos, las personas y las búsquedas JQL en la suya (consulta Enlaces a Jira).

Los informes existen para el problema que aparece cuando Jira Automation crece a lo largo de una organización: ninguna pantalla de proyecto individual explica la malla de automatización completa. Una instantánea de exportación puede contener reglas locales de proyecto, reglas multiproyecto, reglas globales, reglas copiadas con pequeñas diferencias, etiquetas que significan cosas distintas en distintos equipos, y acciones de webhook o correo que conectan Jira con otros sistemas. Los informes convierten ese estado JSON local en un inventario y una superficie de revisión que administradores, auditores y equipos de migración pueden discutir sin acceso en vivo a Jira.

Inventory

Qué hace: cataloga cada regla de la instantánea de exportación, agrupada por scope. Es el mapa base del estado de la automatización — qué existe, dónde vive, si está habilitada y qué triggers, condiciones, acciones, etiquetas, actores y ramas componen cada regla.

ajat report inventory \
  --input-dir ./jira-automations-backup \
  --output-file inventory.html

Lo que obtienes:

• Tarjeta hero de titular más tarjetas de métricas: total / habilitadas / deshabilitadas / scopes únicos / con ramificación / con capacidad de encadenamiento / sin etiquetar.
• Desglose por familia de scope con gráficos de barras en línea (global, proyecto único, multiproyecto, otro scope, desconocido).
• Tablas de Editadas recientemente y Reglas más antiguas — la primera muestra la actividad actual, la segunda muestra reglas potencialmente obsoletas que nadie ha tocado en mucho tiempo.
• Lista de Reglas sin etiquetar (se muestra solo cuando falta alguna etiqueta).
• Top de scopes / triggers / acciones con barras proporcionales al conteo; los tipos de trigger y acción se humanizan (p. ej. jira.jql.scheduled → Scheduled (JQL)).
• Chips de Top de etiquetas y tabla de Top de actores.
• Sección People — una tabla por cuenta que cubre a todos los que el estado referencia (propietarios, actores, colaboradores y referencias de componentes), con conteos de reglas por rol, total de reglas, tipo de cuenta y estado activo/desactivado.
• Una tarjeta expandible por regla con insignias de estado, un diagrama de flujo Trigger → Conditions → Actions → Branches (con pistas en línea como la expresión cron de los triggers programados, extractos de JQL y nombres de campo destino), un botón de copiar al portapapeles para el UUID y una cuadrícula de metadatos (UUID, estado, etiquetas, actualizada, creada, actor, notify-on-error, archivo de origen).

Huella de integración

El informe de inventario responde una pregunta de seguridad y cumplimiento que la interfaz de Jira no puede: ¿adónde envía datos nuestra automatización y a quién? La huella de integración inventaría cada servicio externo que el estado alcanza — espacios de chat, destinatarios de correo, endpoints de webhook y servicios en la nube. Úsala durante revisiones de proveedores, auditorías de egreso de datos y revisiones de acceso para ver las dependencias salientes de la automatización en un solo lugar.

El informe de inventario es la primera parada adecuada cuando un equipo pregunta: «¿Qué automatización tenemos realmente?». Muestra las reglas globales y multiproyecto que es fácil pasar por alto cuando cada proyecto se revisa de forma aislada.

Collision

Qué hace: encuentra reglas que se solapan o hacen lo mismo — la proliferación por copiar-pegar que se acumula a medida que la automatización se clona entre proyectos.

Por qué es útil: las reglas duplicadas suponen más mantenimiento, más tiempo de ejecución y más lugares donde la misma lógica puede desincronizarse. Este informe te da una lista corta de candidatos a consolidación y de reglas en conflicto que compiten por las mismas incidencias.

ajat report collision \
  --input-dir ./jira-automations-backup \
  --output-file collision.html \
  --similarity 0.7

Se detectan dos tipos de duplicación:

• Duplicados de comportamiento — reglas cuyos pasos son casi idénticos (trigger, condiciones y acciones con sus parámetros clave), agrupadas por similitud de Jaccard sin importar el scope, de modo que la misma automatización copiada y pegada en muchos proyectos aparece como una sola familia. Cada grupo muestra el comportamiento compartido, la similitud de cada miembro y en qué difiere. Ajústalo con --similarity.

• Huellas de solapamiento — coincidencias estructurales más gruesas:

  Grupo	Confianza	Qué muestra
  Huella exacta	ALTA	Mismo scope + trigger + paquete de condiciones
  Trigger compartido	MEDIA	Mismo trigger en el mismo scope
  Condición compartida	BAJA	Fragmento de condición repetido bajo el mismo trigger
  Etiqueta compartida	BAJA	Reglas marcadas con la misma etiqueta de automatización

La confianza refleja cuán específica es la coincidencia. Inspecciona siempre las reglas listadas antes de consolidar — a veces los duplicados son intencionales (p. ej. una regla por clon de proyecto). El informe muestra candidatos para revisión humana; nunca afirma que una regla esté mal.

Consistency

Qué hace: audita la higiene de etiquetas, la nomenclatura, la propiedad y la postura de gobernanza en todo el estado.

Por qué es útil: es la lente de legibilidad. A medida que participan más proyectos y administradores, las etiquetas y los nombres se dispersan y la propiedad se vuelve difusa. Este informe muestra si los equipos usan el mismo lenguaje para los mismos tipos de automatización — valioso antes de migraciones, limpieza de plataforma y revisiones de acceso.

ajat report consistency \
  --input-dir ./jira-automations-backup \
  --output-file consistency.html

Lo que obtienes:

• Inventario de etiquetas: cada etiqueta con su conteo de reglas y los proyectos a los que pertenecen sus reglas, cada proyecto una sola vez, más una marca Global u Otro cuando la llevan reglas globales o de otro scope. Ordena por la columna Proyectos para encontrar las etiquetas más extendidas.
• Etiquetas similares: grupos detectados mediante distancia de Levenshtein normalizada (umbral 0.82) — detecta erratas como triage frente a triag.
• Nombres de regla similares: el mismo algoritmo sobre los nombres de las reglas — revela reglas copiadas y pegadas con nombres ligeramente distintos.
• Familias de capacidad: reglas agrupadas por familia de acción inferida (creadoras de incidencias, modificadoras de incidencias, remitentes de correo, invocadoras de webhook).
• Gobernanza e higiene: distribuciones de manejo de errores y de acceso de edición, más desgloses de reglas con fallo silencioso y de acceso restringido.
• Propiedad: quién crea y ejecuta la automatización, y las reglas «huérfanas» cuya identidad de autor o de ejecución está desactivada.

Risk

Qué hace: escanea el estado en busca de riesgo de gobernanza y operativo, puntúa cada regla y clasifica las que necesitan atención — un panel de salud con una calificación general.

Por qué es útil: la escala esconde problemas. Este informe encuentra la automatización que falla en silencio, sin dueño, obsoleta, derrochadora o que filtra datos — los problemas que no se ven regla por regla en Jira. Ejecútalo trimestralmente, o compáralo a lo largo del tiempo.

ajat report risk \
  --input-dir ./jira-automations-backup \
  --output-file risk.html

Cada regla se comprueba contra los hallazgos de abajo. Cada hallazgo vale un número fijo de puntos, la puntuación de una regla es la suma de los hallazgos que dispara, y el informe lista los motivos exactos junto a cada regla — un chip por hallazgo, coloreado según la severidad.

Los hallazgos de coste cuentan solo reglas habilitadas, porque una regla deshabilitada no dispara nada. Jira factura la automatización en pasos — cada disparador, condición, acción e iteración de rama que se ejecuta — así que estas son las reglas que hacen subir el consumo. Los hallazgos de gobernanza se aplican también a las reglas deshabilitadas, porque tratan de lo que la regla haría y de quién puede arreglarla. La leyenda de puntos del informe se genera a partir de la misma tabla que usa la puntuación, y cada hallazgo de coste lleva la marca reglas habilitadas.

Una búsqueda cuenta con ventana temporal cuando compara un campo de fecha con >, >= o = contra una fecha relativa, now() o una función de inicio (updated >= -1d, duedate = startOfDay()), está anclada a work items concretos (key = {{issue.key}}, parent = ABC-1) o es una búsqueda de texto. updated <= -7d no es una ventana: selecciona todo lo que tenga más de una semana, que crece sin límite.

Esa lectura del texto JQL es un recurso de respaldo. Exporta con --probe-jql y el informe usa el recuento de Jira en su lugar: una búsqueda de más de 1000 work items se señala con su tamaño («la búsqueda programada coincide con 3.588 work items») y una búsqueda contada por debajo de 1000 no se señala. En un inventario real de 654 reglas, el texto por sí solo señaló nueve búsquedas; la sonda descartó ocho y confirmó una. Consulta Medir el tamaño de las búsquedas.

Con historial de ejecución de ajat audit-log — la exportación CSV del registro de auditoría de Jira, importada, o el propio registro, descargado (experimental) — una tabla Reglas más activas ordena las 20 reglas con más ejecuciones, junto a cuántas de ellas no hicieron nada, las limitaciones, el mayor número de work items que tocó una ejecución y la puntuación de riesgo, para leer coste y riesgo juntos.

La vista general califica el inventario de A a F a partir de los puntos de todas las reglas y lista las reglas de mayor riesgo, cada una con un chip por hallazgo en su columna Por qué; una tabla Riesgo por proyecto enruta los hallazgos al equipo propietario y enlaza cada proyecto con Jira. La lista de cada hallazgo dice, bajo cada regla, por qué está ahí, con los mismos chips coloreados por severidad («Secreto: clave y token de webhook de Google Chat en la URL», «Limitada 7 veces en la ventana de auditoría»). La búsqueda también encuentra hallazgos y motivos: escribir secret o throttled encuentra las reglas, no solo la sección. Añade --state enabled para puntuar solo las reglas que se ejecutan (consulta Flags comunes).

Los secretos nunca se imprimen. Un hallazgo de secreto dice qué tipo de secreto es y dónde está en la regla («clave y token de webhook de Google Chat en la URL (Webhook › url)»), nunca ninguna parte del valor. Cada informe enmascara además las credenciales en el texto de configuración que cita; consulta Compartir informes de forma segura.

Workflow

Qué hace: renderiza cada regla como un diagrama de flujo de arriba hacia abajo más un «runbook» paso a paso de exactamente lo que hace — apto para impresión, una regla por página.

Por qué es útil: es la forma más rápida de entender una automatización sin leer JSON en bruto ni hacer clic por el constructor de Jira. Perfecto para revisiones, auditorías, aprobaciones de cambios e incorporación de alguien nuevo al estado. Imprime o Guarda como PDF para un documento limpio por regla.

ajat report workflow \
  --input-dir ./jira-automations-backup \
  --output-file workflow.html

Cada regla muestra su árbol de componentes como un diagrama SVG en línea (trigger → condiciones → acciones, con las ramas indentadas) junto a una lista de pasos en lenguaje sencillo («Cuando se programe cada 5 minutos → Para incidencias relacionadas → Entonces editar Expected Release»), las identidades de propietario y de ejecución, la complejidad y los sistemas externos con los que se integra. Los diagramas son SVG en línea sin JavaScript, así que la función Imprimir / Guardar como PDF del navegador produce un runbook limpio por regla.

Navegar por los informes

Cada informe comparte la misma interfaz:

• Un único lenguaje visual. Una regla, una persona, un proyecto y un estado se ven igual en todos los informes: una regla deshabilitada lleva la insignia Deshabilitada en todas las listas; una persona es su foto y su nombre, con enlace a su perfil de Jira y un punto solo cuando la cuenta está inactiva o sin resolver; un proyecto es un chip de color con la clave y el icono del proyecto que enlaza con Jira; el Abrir en Jira de cada regla lleva a la página propia de esa regla; y la severidad (riesgo) y la confianza (colisiones) comparten una misma paleta, de alta a baja. Los números grandes llevan separadores de miles en todas partes, gráficas incluidas. La programación de una regla se clasifica una sola vez, así que las gráficas, la marca Cada hora o más del inventario y los hallazgos de riesgo siempre coinciden.
• Búsqueda global. El campo de la barra lateral filtra cada elemento buscable de la página — tarjetas de regla, filas editadas recientemente, filas de etiquetas, encabezados de grupo, hallazgos de riesgo y sus motivos. Escribe varias palabras en cualquier orden: cada palabra tiene que aparecer en algún lugar de la entrada, así que kpi edit encuentra Edit and Check — Monitor and Modify KPI Value. Cada palabra se resalta en línea. Las secciones que vienen plegadas se abren mientras contienen una coincidencia y se vuelven a cerrar cuando se limpia la búsqueda.
• Contador de resultados. Bajo el cuadro de búsqueda, por ejemplo 37 of 648 rules. Cuenta aquello de lo que trata el informe — reglas en los informes de inventario y workflow, grupos en colisiones y consistencia, hallazgos en el informe de riesgo.
• Sin resultados. Cuando nada coincide, el informe lo dice y ofrece un botón que limpia la búsqueda y todos los chips.
• Listas largas. Las listas que pueden alargarse — reglas sin etiquetar, cada categoría de riesgo — están completas en el archivo y se recortan tras unas 25 filas detrás de un botón Mostrar todo. Una búsqueda que coincide más abajo abre la lista por ti, así que los recuentos y la búsqueda siempre concuerdan con lo que puedes alcanzar.
• Chips de filtro (inventory y workflow): agrupados en Estado, Scope y Rasgos. Una regla debe coincidir con un chip de cada grupo que uses, y con cualquier chip dentro de un grupo, así que Deshabilitada + Programada muestra las reglas que son ambas cosas, mientras que dos scopes muestran cualquiera de los dos. El panel describe en palabras la combinación activa. Los chips acotan solo el catálogo de reglas; las tablas de resumen y la sección Personas siguen únicamente la consulta de texto. Los chips son botones: se alcanzan con Tab y se alternan con Espacio o Intro.
• Desplegable de orden (solo inventory): nombre A→Z / Z→A, actualizadas más nuevas / más antiguas, para las tarjetas de regla.
• Tablas ordenables. Haz clic en la cabecera de cualquier tabla para ordenar por esa columna; vuelve a hacer clic para invertir el orden. Los números se ordenan de mayor a menor, el texto de A a Z, y la cabecera muestra ▲ o ▼. Las columnas se ordenan por su valor real, no por lo que se imprime: un «·» cuenta como cero, «3 d ago» se ordena por fecha, una barra por su número, una persona por su nombre, una severidad de alta a baja. Las columnas de texto libre (el Por qué del informe de riesgo) no se ordenan. Ordenar conserva la búsqueda actual, las cabeceras funcionan desde el teclado, y los lectores de pantalla anuncian cada tabla por su nombre y cada cabecera con su orden.
• Pantallas estrechas. Las tablas anchas se desplazan lateralmente dentro de su sección en lugar de ensanchar la página.
• Secciones plegables. Cada sección titulada se pliega; despliega o pliega todas desde los botones de la barra lateral o con los atajos e / c.
• Panel de Analytics. Las gráficas del inventario son las mismas en todos los informes. Se abren por defecto en inventory y empiezan plegadas en los demás, para que el contenido propio de cada informe vaya primero. La gráfica Con qué frecuencia se ejecutan las reglas programadas agrupa las reglas programadas por el tiempo entre dos ejecuciones: menos de una hora, 1–23 horas, 1–6 días, 1–4 semanas y mensual o menos. La tarjeta, el chip y la insignia Cada hora o más del inventario cuentan las reglas que se ejecutan con una hora o menos de separación.
• Alternador de tema claro / oscuro en la barra superior derecha; la elección se guarda en localStorage. Sin una preferencia explícita, el informe respeta la del sistema operativo, sin destello del tema equivocado.
• Atajos de teclado: / enfoca la búsqueda, Esc la limpia desde cualquier punto de la página, e despliega todos los pliegues, c los pliega. Cada uno actúa solo cuando se pulsa por sí solo, así que Copiar, Buscar y Guardar del navegador siguen funcionando. El Buscar del propio navegador (⌘F / Ctrl+F) es la herramienta adecuada para el texto que el índice de la barra lateral no cubre, como las descripciones de reglas y los detalles de pasos.
• Hoja de estilos de impresión. La barra de herramientas, la barra lateral, la búsqueda, los chips y los botones de copiar se ocultan; las secciones se renderizan en un diseño paginado apto para exportar a PDF (⌘P / Ctrl+P). Imprimir abre primero todas las secciones plegadas y las listas recortadas, para que se imprima el informe entero, y las vuelve a cerrar después. Las fotos se imprimen con la página.
• Las direcciones de correo son enlaces. La tabla de destinos de notificación y las insignias de destinatarios por regla son enlaces mailto:, con un botón de copiar junto a cada dirección de la tabla.

Los informes usan HTML moderno (<details>, CSS Grid, propiedades personalizadas) y apuntan a navegadores modernos — Chrome, Safari, Firefox y Edge actuales.

Flags comunes

Cada subcomando de informe acepta:

collision acepta además --similarity (predeterminado 0.7) para ajustar el umbral de agrupamiento por comportamiento de 0 a 1.

# Riesgo sobre las reglas que realmente se ejecutan.
ajat report risk --input-dir ./jira-automations-backup --output-file risk-live.html --state enabled
 
# Inventario de reglas deshabilitadas, para una revisión de limpieza.
ajat report inventory --input-dir ./jira-automations-backup --output-file disabled.html --state disabled

Fotos y uso sin conexión

Las personas aparecen con su foto de Jira y un enlace a su perfil, y los proyectos con su icono. Las fotos vienen de la exportación: ajat export descarga el avatar de 48×48 de cada cuenta resuelta en .ajat_external_directory.json y el icono de cada proyecto en .ajat_projects.json (consulta Resolver identidades de usuario), y un informe embebe cada una una sola vez, así que una página con la misma persona en cuatrocientas reglas lleva una sola copia de su foto, de unos 4 KB. El informe sigue siendo un único archivo que abre sin conexión, se puede adjuntar a un ticket y no descarga nada de Atlassian al abrirse.

Una cuenta sin foto — la exportación se hizo con --avatars=false, la descarga falló o la cuenta no se pudo resolver — muestra iniciales de color en su lugar. Las exportaciones anteriores a las fotos muestran iniciales para todo el mundo hasta el siguiente ajat export.

Pasa --remote-avatars para apuntar a las imágenes alojadas en Jira en lugar de embeberlas. La página es más pequeña, pero solo muestra caras con conexión, y cada apertura se lo comunica a Atlassian — también cuando la abre alguien con quien compartiste el inventario. En una exportación de 654 reglas son aproximadamente 1400 peticiones de imagen por apertura. Los iconos de proyecto siguen embebidos en cualquier caso: Jira no tiene una dirección pública para ellos, y un inventario tiene un puñado de un kilobyte cada uno.

ajat report inventory \
  --input-dir ./jira-automations-backup \
  --output-file inventory.html \
  --remote-avatars

Enlaces a Jira

El Abrir en Jira de cada regla abre la página propia de esa regla. Jira guarda una regla de un solo proyecto bajo la configuración del proyecto, en una ruta que depende del tipo y el estilo del proyecto (/jira/software/c/projects/KEY para un proyecto de software gestionado por la empresa, /jira/software/projects/KEY para uno gestionado por el equipo, /jira/core/... para los de negocio y /jira/servicedesk/... para los de gestión de servicios), que la exportación registra en .ajat_projects.json. Las reglas globales, multiproyecto y de otro scope — y todas las reglas de una exportación anterior a ese archivo — se abren bajo la página global de automatización, que las lista todas.

El enlace a Jira de la cabecera sigue yendo a la página global de automatización; un chip de proyecto abre el proyecto, también en la tabla Riesgo por proyecto del informe de riesgo; una persona abre su perfil; y una búsqueda JQL mostrada en una tarjeta de regla del inventario ejecuta esa búsqueda en Jira. Una búsqueda de la que la página enmascara un secreto nunca se enlaza.

Temas para uso de marca blanca

Los informes usan propiedades personalizadas de CSS para cada color y radio. Sobrescríbelas con un archivo de tema YAML para adecuarlas a la marca de tu organización:

# brand-theme.yaml
colors:
  bg: "#0d1117"
  surface: "#161b22"
  ink: "#e6edf3"
  accent: "#7c3aed"
  trigger: "#f59e0b"
  condition: "#a855f7"
  action: "#22c55e"
  branch: "#06b6d4"

ajat report inventory \
  --input-dir ./jira-automations-backup \
  --output-file inventory.html \
  --theme-file ./brand-theme.yaml \
  --title "Acme — Jira Automation Inventory"

Las dos mitades de cada sobrescritura se validan contra una lista de permitidos: la clave debe ser un identificador CSS simple, y el valor un color hexadecimal, un color o palabra clave con nombre, una longitud o porcentaje numérico, o una llamada rgb() / rgba() / hsl() / hsla(). Todo lo demás se descarta — incluido url(...), que haría que un informe autocontenido descargara un recurso remoto. Las sobrescrituras de color no pueden cambiar un informe más allá de sus colores.

Nombrar tus propios servicios

Los informes nombran los servicios conocidos («Slack», «Microsoft Teams») allí donde una regla los llama: las integraciones del inventario, las llamadas externas del informe de riesgo y las páginas de workflow. Cualquier otro host se muestra por su dominio. El mismo archivo de tema puede nombrar tus propios hosts y los de tus proveedores:

# brand-theme.yaml
services:
  factorialhr.com: Factorial HR
  api.acme.internal: Acme API

Una clave coincide con el propio host y con todos sus subdominios, y gana la clave coincidente más larga, así que eu.api.acme.internal arriba es «Acme API». Una clave debe ser un nombre de host en minúsculas con al menos un punto, y una etiqueta de 1 a 40 caracteres sin <, >, " ni saltos de línea; las entradas que no superan alguna de las dos comprobaciones se descartan. Tus nombres se usan antes que los integrados, así que un tema también puede renombrar un servicio que los informes ya conocen.

Compartir informes de forma segura

Los informes citan partes de la configuración de tus reglas: hosts de webhook, destinatarios y asuntos de correo, texto de comentarios, JQL y descripciones de reglas. No imprimen URLs de webhook completas ni valores de cabeceras, y cada fragmento de configuración citado se enmascara: las formas de token y los valores de key=, token= y parámetros de URL similares se sustituyen por ••••••. El hallazgo Secretos expuestos del informe de riesgo lista las reglas que llevan una credencial, para que puedas rotarla y moverla a un almacén de secretos.

El enmascarado detecta formas conocidas, no cualquier secreto posible. Revisa un informe antes de enviarlo externamente:

grep -i 'password\|token\|secret\|apikey' inventory.html

Un informe enriquecido con identidades resueltas contiene datos personales: nombres para mostrar, fotos y cualquier dirección de correo que Jira expusiera. Trátalo como cualquier archivo que contenga datos personales.

Relacionado

• ajat export — construye la instantánea de exportación local que consumen los informes.
• ajat audit-log — incorpora el historial de ejecución de reglas a la exportación, para que el informe de riesgo vea las ejecuciones limitadas, las ejecuciones sin acciones y las reglas más activas.
• ajat diff — compara dos instantáneas de exportación para revisar la deriva a lo largo del tiempo.
• ajat search — consulta el tenant en vivo para obtener resúmenes de reglas frescos sin exportar.
• Utilidades — doctor, tree, support y el resto de la superficie de diagnóstico.