¿Qué pasa si eliminas algo en Jira Cloud?
Cuando empezamos a trabajar con Jira, una de las preguntas más recurrentes por parte de los nuevos usuarios es: ¿qué pasa si elimino algo? ¿Puedo recuperarlo? ¿Existe la opción de deshacer o volver atrás?
Sigue leyendo, y encontrarás qué sucede en cada caso, según el elemento de Jira que elimines, si puedes recuperarlo o no y cómo proceder.
Lo vamos a separar en dos grandes grupos, por una parte los Usuarios internos de la herramienta, también conocidos como Agentes o Servicedesk Users, y por otra, los Administradores.
Para los usuarios de un proyecto:
Si en un ticket o tarea eliminamos el valor de un campo o lo sustituimos por otro, en el historial de este, encontraremos el valor anterior, con lo cual técnicamente no perderíamos el valor. Podríamos recuperarlo en cualquier momento.
No pasaría así con los adjuntos y los comentarios de texto, con o sin adjuntos, que agreguemos en el ticket. Si se eliminan estos, no se podrán recuperar. Habría que subirlos de nuevo.
Tampoco podemos recuperar los registros de horas. Si alguien elimina el registro de horas imputadas en una incidencia o petición, perderemos ese valor. Realmente podríamos recuperar el valor imputado porque nos aparecerá en el histórico, pero no podríamos recuperar la hora en la que se realizó el trabajo, ni el comentario del trabajo. Es decir, si yo trabajo en un ticket un lunes de 17:00 a 18:00 y lo imputo el miércoles, porque se me ha pasado imputarlo el lunes, a la hora de crear el log del trabajo, fijaré que la fecha de imputación fue el lunes de 17:00 a 18:00. Si elimino el log, solo tendremos el tiempo imputado en la fecha que fue imputado, pero que no tiene que coincidir con la fecha que fue realizado, además de perder el comentario de la imputación.
Si eliminamos el ticket, no habrá manera de recuperarlo salvo que usemos alguna aplicación externa como ‘Restore Deleted Issues’, que tiene que haber sido instalado en la instancia, antes de que el ticket fuera eliminado. No podemos usarlo a posteriori si ya hemos eliminado la tarea.
Eso sí, la persona que ejecute cualquiera de estas acciones quedará en el historial del ticket, así que sabremos quién ha sido el responsable de la eliminación.
El único caso que no deja rastro en el historial es la eliminación de un ticket o tarea. Es posible que Atlassian agregue esta funcionalidad, ya que muchos usuarios la han solicitado.
Por este motivo, la posibilidad de eliminar comentarios (propios y ajenos), registro de horas en incidencias (propios y ajenos), adjuntos (propios y ajenos) o tareas, debería estar reservada a los administradores o a un grupo limitado de usuarios ya que, como se ve, tiene cierto riesgo.
Otra cosa que no podemos recuperar si los eliminamos, son los filtros. Una vez eliminados, no se pueden recuperar de forma nativa.
No sucede lo mismo con los paneles o dashboards. En este caso si los eliminamos, tendremos 60 días para recuperarlos.
Para recuperar un panel o dashboard que fue enviado a la papelera, tendremos que acceder al menú Sistema, y en él buscar la opción Paneles. Haremos clic en Mostrar paneles movidos a la papelera para poder visualizarlos. Una vez localizado, haremos clic en los tres puntos de la derecha para más tarde hacer clic en Restaurar.
Para los administradores de Jira
En este caso existen más opciones disponibles, que solo los administradores pueden ejecutar. Por ejemplo:
Formularios en Jira Service Management
Si queremos eliminar un formulario (o Forms) que utilizamos en un proyecto de Jira Service Management la herramienta nos dejará hacerlo pero indicándonos el tipo de solicitud al que está conectado (si lo estuviera) y por lo tanto lo que podría suponer. Esta opción también la pueden realizar los administradores de proyecto.
Además, nos confirmaría que las siguientes solicitudes carecerán de este formulario pero que las ya existentes no lo perderán.
Si eliminamos un componente y este ha sido utilizado en algún ticket, nos preguntará si de verdad queremos eliminarlo, y perderlo definitivamente (irrecuperable) o si queremos fijar a todos los tickets que tienen ese componente, que va a ser eliminado, otro componente.
Si eliminamos una versión, esta será también irrecuperable.
Formularios, componentes y versiones, también pueden ser eliminadas por administradores de proyecto.
Utilizando Jira Software, emplearemos tableros. Si estos fueran eliminados, no podríamos recuperarlos, aunque este hecho no afectaría a las incidencias del tablero ni completaría ni eliminaría ningún sprint activo.
Otra cosa que no deberíamos eliminar, mientras figuren como assignee, reporter, etc, son los Agentes. Es decir, las personas que han trabajado dentro de un proyecto, los cuales han abierto tickets, gestionado tickets, o están en algún campo de tipo selector de usuarios.
Si los eliminamos y luego los buscamos mediante una jql, el nombre no aparecerá y tendremos que buscar las issues por el id de usuario, lo que puede suponer una tarea bastante complicada.
Incidencias: los tipos de incidencias podemos borrarlos siempre y cuando no tengamos incidencias con ese tipo asignado, si no tendremos que moverlo a otro tipo diferente que sí exista.
Esquemas de tipos de incidencias: podemos eliminarlos y no serán recuperables, pero la herramienta utilizará el esquema por defecto en el proyecto donde estuviera conectado el esquema de tipos de incidencias que vamos a eliminar. Así que siempre quedaría un esquema asociado al proyecto.
Flujos de trabajo: los podemos eliminar y serán irrecuperables, pero no pueden estar activos, es decir, no pueden estar en ningún esquema de flujos si este está también activo.
Esquemas de flujo de trabajo: igual que los flujos, solo podemos eliminarlos (y serán irrecuperables) si no están activos.
Pantallas: las podemos eliminar y serán irrecuperables, siempre que no estén conectadas a un Esquema de pantallas o apliquen en alguna transición de un flujo de trabajo que está en producción.
Esquemas de pantallas/Esquemas de pantallas por tipo de incidencia: los podemos eliminar y serán irrecuperables, pero para hacerlo no tienen que estar conectados a ningún proyecto.
Campos personalizados: si tenemos un campo y lo eliminamos, el campo y la información que contiene en todas las issues donde se tenga valor, se guardará en la papelera durante 60 días.
Pasados esos días, perderemos el campo y los datos que tenga almacenados pertenecientes a cada incidencia.
Si quisiéramos recuperar el campo, haremos clic en la rueda dentada para luego hacer clic en Incidencias. Luego buscaríamos el menú Campos personalizados.
Una vez llegados al menú Campos personalizados, haremos clic en la pestaña En papelera. Acto seguido hacemos clic en los tres puntos suspensivos de la derecha, para más tarde hacer clic sobre Restaurar campo, en el campo que queremos restaurar.
Estados: podemos eliminarlos y serán irrecuperables, pero solo podemos eliminarlos si previamente los eliminamos de los flujos de trabajo que están en producción.
Resoluciones: podemos eliminarlas y serán irrecuperables, pero si hay incidencias en las que estamos utilizando esa resolución que vamos a eliminar, la herramienta nos obligará a seleccionar una nueva resolución.
Prioridades: podemos eliminarlas y serán irrecuperables, pero si hay incidencias con esa prioridad utilizándose, antes de eliminarlas la herramienta nos obligará a seleccionar una prioridad para esas incidencias que se van a quedar ‘huérfanas’.
Esquema de seguridad de incidencias: podemos eliminarlo y no será recuperable, pero para hacerlo el esquema no tiene que estar conectado con ningún proyecto.
Esquemas de notificaciones: podemos eliminarlo y no será recuperable, pero para hacerlo el esquema no tiene que estar conectado con ningún proyecto.
Esquemas de permisos: podemos eliminarlo, aunque no se recuperará. Si está conectado con algún proyecto, a este se le asignará el esquema de permisos por defecto.
Otra opción que no podremos recuperar si la eliminamos, es la de las automatizaciones, así que tendremos que asegurarnos muy bien antes de eliminar.
Y, por último, los proyectos. Si los eliminamos, quedarán almacenados en la papelera durante 60 días. Pasados esos días, se eliminará de forma permanente.
Hay una forma diferente para que los usuarios no puedan ver un determinado proyecto: archivarlo.
Para recuperarlo o sacarlo del archivo primero tenemos que ir al menú Proyectos. Para llegar a él, haremos clic en la rueda dentada situada en el ángulo superior derecho de la pantalla y después en Proyectos.
Si previamente lo hubiéramos eliminado y lo quisiéramos recuperar, nos iríamos al menú Papelera, buscaríamos el proyecto a restaurar, haríamos clic en los tres puntos de la derecha y luego haríamos clic en Restaurar.
Si previamente lo hemos archivado y lo queremos recuperar haremos clic en Archivar, luego buscaremos el proyecto a recuperar, hacemos clic en los tres puntos de la derecha, para luego hacer clic en Restaurar.
Y tras esto, ¿cuál sería la recomendación antes de eliminar algo?
En primer lugar, la recomendación, como norma general, sería que los agentes o usuarios de Jira no tuvieran permisos para eliminar lo que comentamos anteriormente. Este trabajo debe reservarse a los administradores de instancia o a los administradores de proyecto, para evitar posibles errores.
Siempre que un administrador vaya a eliminar una issue o varias, si lo va a realizar mediante un borrado masivo, debe cerciorarse de que esas issues no van a ser necesarias nunca más, porque una vez eliminadas, las perdemos para siempre. Mejor siempre dos revisiones que una.
Como opción, podríamos crear un proyecto exactamente igual al proyecto donde están las issues que queremos eliminar y utilizarlo como backup. De tal forma que podamos acudir a esas issues en caso de necesitarlo. Se podrían quitar permisos a todos los usuarios, para que simplemente sea un proyecto de consulta para los administradores y un sitio al que ir si necesitamos recuperar alguna issue. Pasado un tiempo prudencial se podría eliminar de forma permanente.
Y como recomendación, tanto para Agentes y usuarios como para Administradores de Jira, sentido común: si algo es irrecuperable tenemos que asegurarnos, antes de ejecutar el cambio, del impacto que va a tener en nuestra instancia.
Adolfo Rodríguez 31 de enero de 2023
