# Actividad del workspace > Registro de auditoría de la organización para propietarios y administradores. La pestaña **Actividad** (`/workspace/activity`) muestra un feed append-only de los cambios relevantes en la organización activa: quién hizo qué, sobre qué entidad y cuándo. ## Quién puede verlo Solo **propietarios** y **administradores** pueden abrir el feed. Los miembros y visualizadores ven el mensaje estándar de permisos y la API responde `403`. ## Qué se registra Cada mutación de dominio exitosa emite un evento por petición HTTP, por ejemplo: - Proyectos, suites y casos de prueba (crear, actualizar, mover, archivar, eliminar) - Campos personalizados y ediciones agrupadas de casos (un solo `test_case.updated` cuando un PATCH cambia campos, pasos, parámetros o valores a la vez). Un cambio en los parámetros o las combinaciones excluidas de un caso aparece en el detalle del evento, como **Parámetro agregado**, **Parámetro eliminado** o **Combinaciones excluidas** - Parámetros compartidos: creados, actualizados o eliminados. Un caso que alcanza un cambio de un parámetro compartido queda registrado como modificado a través de ese parámetro. Consulta [Casos de prueba parametrizados](https://docs.probara.net/es/guides/parameterized-test-cases/#parámetros-compartidos) - Miembros desactivados o reactivados, y miembros que salen (el trabajo abierto de un miembro desactivado o que salió se le desasigna), invitaciones, tokens de API y aplicaciones conectadas (OAuth y MCP) revocadas cuando un miembro se desactiva o sale - Inicio de sesión único: conexión creada, actualizada o eliminada; conexión probada; exigencia activada o desactivada; la política de inicio de sesión cambió (añadir automáticamente a las personas nuevas o el rol predeterminado); acceso de emergencia del propietario usado; dominios reclamados, verificados, dejados sin verificar tras una caducidad o eliminados; miembros que se unieron mediante inicio de sesión único; y cuentas existentes vinculadas a una identidad de inicio de sesión único - Aprovisionamiento SCIM: SCIM activado o desactivado, tokens SCIM creados, revocados o caducados, personas aprovisionadas, modificadas, desactivadas, reactivadas o eliminadas mediante SCIM (un cambio de rol hecho por SCIM muestra el rol anterior y el nuevo), ajustes de roles de SCIM modificados (origen del rol, modo estricto, grupo predeterminado) y asignaciones de roles por grupo modificadas - **Ejecuciones (runs)** — crear, actualizar, cerrar (incluido el cierre automático en cuanto todos los casos tienen resultado), abortar, eliminar, clonar ("Volver a ejecutar"), añadir/quitar casos, marcar casos y pasos, asignaciones, reintentos y ediciones del resultado real Los eventos más antiguos que la [ventana de retención del historial](https://docs.probara.net/es/guides/test-runs/#retención-de-datos) de tu plan se eliminan automáticamente. ## Filtrar el feed Usa **Añadir filtro** sobre la línea de tiempo para acotar el feed de la organización: - **Actor** filtra los eventos realizados por un miembro de la organización. Los eventos cuyo usuario se eliminó después permanecen en el feed, pero no coinciden con un filtro de actor miembro. - **Tipo de entidad** filtra por el tipo de objeto que cambió, como proyecto, ejecución, defecto, campo personalizado, miembro, invitación o token de API. Selecciona más de un tipo de entidad para combinarlos con OR. Los filtros se reflejan en la URL, así que propietarios y administradores pueden compartir una vista de actividad acotada. Cambiar filtros recarga el feed desde el evento coincidente más reciente; usa **Limpiar filtros** para volver a la línea de tiempo completa. ### Actividad de runs en el feed Los eventos de run usan etiquetas capturadas al momento del cambio, así la línea de tiempo sigue siendo legible aunque un caso se renombre o elimine después. | Qué ocurrió | Qué verás | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Run creado | Cantidad de casos y, si aplica, entorno, asignado por defecto e hito | | Run actualizado | Diff colapsable de nombre, descripción, asignado por defecto, entorno o hito | | Run cerrado | Scorecard final (aprobados / fallidos / bloqueados / omitidos / sin probar, duración total, resultado proyectado). Se ve igual tanto si el cierre fue automático (todos los casos ya tenían resultado) como si fue con **Completar**. | | Run eliminado | Nombre del run (texto plano, sin enlace), scorecard final y si estaba abierto o cerrado al borrar | | Resultado real editado | Contexto del paso con diff de texto `de → a` en la ejecución en vivo | | Run clonado ("Volver a ejecutar") | Nombre del run origen y el nombre/etiqueta del run nuevo | | Casos añadidos | Cuántos casos se agregaron (hasta 20 nombrados en el payload) | | Caso marcado | Enlace al caso (`PROYECTO-42 · Título`), chip de estado de → a, tiempo transcurrido opcional | | Paso marcado | Enlace al caso, posición/acción del paso, chip de estado, estado del caso tras el marcado | | Caso asignado | Quién asignó a quién (auto-asignación al abrir vs cambio manual) | | Caso reintentado | Estado anterior restablecido a sin probar y tiempo borrado cuando corresponda | | Caso eliminado | Identidad del caso y estado al quitarlo | | Marca / asignación / reintento / eliminación masivos | Una fila por gesto con el conteo, los primeros IDs de caso y un diff expandible por caso (chips de estado, transiciones de asignado o estado al quitar) | | Envío de resultado masivo | Una fila por gesto: estado, conteo, los primeros IDs de caso y un diff expandible por caso (misma forma que la marca masiva) — el tiempo dividido y cualquier defecto adjunto no se muestran en el diff mismo | Si el run sigue existiendo, el nombre del run en un evento de caso abre la vista de ejecución en ese caso, y en un marcado de caso, en el intento que registró. Los runs eliminados muestran solo texto. ## Actividad dentro de un run Cada vista de ejecución (`/projects/{proyecto}/runs/{run}`) incluye la pestaña **Actividad** junto a **Casos de prueba**. Muestra la misma línea de tiempo agrupada por día y los mismos diffs que el feed del workspace, pero solo para ese run. | Superficie | Quién puede abrirla | API | | ----------------------------- | ----------------------------------------------- | ----------------------------------------- | | **Actividad** del workspace | Propietarios y administradores | `GET /api/v1/orgs/{orgUlid}/audit-events` | | Pestaña **Actividad** del run | Cualquier rol que pueda leer el run (`viewer`+) | `GET /api/v1/runs/{runUlid}/audit-events` | La pestaña se refleja en la URL como `?tab=activity` para enlaces profundos y el botón Atrás del navegador. En un run cerrado la pestaña **Casos de prueba** es solo lectura, pero **Actividad** sigue mostrando todo el historial. Los enlaces al run dentro de la pestaña se omiten porque ya estás dentro de esa ejecución. ## Diseño en línea de tiempo El feed es una **línea de tiempo agrupada por día**: - Los eventos se agrupan bajo encabezados de día (**Hoy**, **Ayer** o una fecha absoluta) con el conteo del día. - Un riel vertical conecta los avatares redondos de cada actor dentro del día. - Cada avatar lleva una **insignia de tipo de acción** (crear, actualizar, mover o eliminar) según el verbo del evento. Usa el pie de página (`mostrando N eventos · cargar más`) para ver entradas más antiguas. Al cargar otra página no se duplica el encabezado del día si los eventos nuevos pertenecen a un día ya visible. ## Detalle de los cambios (diff) Los eventos de tipo `*.updated`, `*.moved` y `member.role_changed` incluyen un diff estructurado que describe **qué campos cambiaron** y **a qué valores**: - **Todos los cambios** (incluso un solo campo) aparecen en un grupo colapsable con el conteo en dos dígitos y la palabra **cambio** o **cambios** según la cantidad (p. ej. `01 cambio`, `03 cambios`). Al expandirlo verás cada campo que cambió por su nombre y, debajo, su valor anterior, una flecha y su valor nuevo. En los textos largos, como una descripción, las palabras que cambiaron se resaltan en cada lado. - Los valores **nulos** se muestran como **Sin valor**. - **Valores largos:** los textos se truncan a 240 caracteres y aparece un botón **Ver más** que despliega el snapshot completo guardado en el momento del cambio. - **Pasos del caso:** cuando un guardado consolidado modifica pasos, el feed muestra un **diff detallado por paso** dentro del mismo grupo: una fila por paso tocado con veredicto (**Añadido**, **Eliminado**, **Modificado**, **Reordenado**), líneas `anterior → nuevo` por acción/datos/resultado esperado (mismo formato y **Ver más** que los campos escalares), cambios de posición e imágenes añadidas o quitadas por nombre de archivo. Los eventos antiguos pueden seguir mostrando solo el conteo (`Pasos: 3 → 5`). Si cambian más de 20 pasos a la vez, se listan los primeros 20 más una fila resumen del resto (los totales por veredicto siguen siendo exactos). - **Definiciones de campos personalizados:** `custom_field.updated` registra cada parte mutable de la definición — propiedades escalares (`title`, texto de ayuda, **Obligatorio**, valor por defecto) como filas `anterior → nuevo`, más líneas en formato frase para **visibilidad por proyecto** (visible en todos los proyectos, paso a proyectos específicos, **sin proyectos** (`Sin proyectos`, misma cadena que la tabla de campos) cuando el alcance queda vacío, o alta/baja por proyecto con nombres capturados) y **lista de opciones** (opciones añadidas, eliminadas o renombradas con nombres capturados). Un reorden puro de opciones sigue usando la acción aparte `custom_field.options_reordered` sin líneas de opciones. Los nombres de campo y referencias son snapshots del momento del cambio, aunque luego se renombren o eliminen. - **Ediciones de hito, entorno y defecto:** `milestone.updated`, `environment.updated` y `defect.updated` incluyen el mismo diff por campo que las demás actualizaciones. Un hito muestra nombre, descripción, fechas (inicio, vencimiento y estimada) e **hito padre** por nombre; los cambios de estado —edición manual o finalización automática— registran el estado `de → a`. Un entorno muestra nombre, slug, descripción, URL y el indicador **Predeterminado**. Un defecto muestra su **responsable** e **hito** por nombre. Estos campos de referencia muestran la etiqueta legible capturada en el momento del cambio, nunca el id interno. Eventos que no son updates (`*.created`, `*.deleted`, `*.archived`, `*.restored`) siguen mostrándose con su plantilla descriptiva sin grupo de cambios. ## Comentarios y notas de revisión Los comentarios en casos de prueba, solicitudes de revisión y defectos muestran su texto como una cita debajo de la línea del evento, no dentro de ella. Si se elimina un comentario, su texto se conserva tachado en la cita, para que el registro muestre qué se quitó. Una decisión de revisión con nota (aprobar, **Pedir cambios** o rechazar) cita la nota de la misma forma. La nota de **Pedir cambios** lleva una barra ámbar. ## Tipos de actor | Actor | Cómo se muestra | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Usuario | Avatar redondo con iniciales y nombre visible o parte local del correo | | Token de aplicación | El logotipo de la aplicación, su nombre y el nombre del token, por ejemplo **JUnit XML · nightly-ci** ([tokens de aplicación](https://docs.probara.net/es/guides/integrations/junit-xml/)) | | Sistema | Icono neutro y etiqueta «Sistema» | Una acción hecha con uno de tus [tokens de API](https://docs.probara.net/es/guides/user-profile/#tokens-de-api) personales te muestra a ti, igual que una acción hecha en la app, con **Desde un token de API** al final de la línea del evento. Si un usuario o un token de aplicación se elimina después, los eventos antiguos permanecen con «Usuario eliminado» / «Token eliminado». ## API relacionada Los integradores pueden leer los mismos datos con `GET /api/v1/orgs/{orgUlid}/audit-events`. Consulta [API de eventos de auditoría](https://docs.probara.net/es/developers/api/audit-events/).