Redmine 7 en municipios: obras, roles y cierre

Mini-caso municipal: Redmine ordena reclamos de obras, responsables, estados y archivos con roles por proyecto, backup y prueba de cierre verificable.

ULTIMA MILLA · Proyectos · 22 de jul de 2026 · 4 min de lectura

Redmine 7 en municipios: obras, roles y cierre

Antes, una cuadrilla cerraba un bache con una foto por chat; después, cada reclamo tuvo obra, responsable, estado y archivo final. El caso es de una municipalidad del Gran Mendoza menor a 50.000 habitantes que necesitaba ordenar obras chicas sin sumar una plataforma cerrada. Redmine 7 permite registrar tareas, roles y documentos por proyecto. Esta nota muestra qué dato se carga, quién lo cambia y cómo se prueba el cierre.

Dónde aparece la obra que nadie puede cerrar

El síntoma llegó con tres listados distintos de tareas: alumbrado, bacheo y arbolado. Cada área tenía prioridades propias y nadie podía demostrar cuándo una orden había pasado de solicitada a terminada. El antagonista era el tablero de corcho del depósito, con tarjetas pinchadas que cambiaban de columna sin dejar hora ni responsable. La cifra que corrige la elección está en la página oficial de descargas de Redmine: Redmine 7.0.0 fue publicado el 30 de junio de 2026, mientras 7.0.x figura como versión estable con soporte completo. La misma página marca 6.1.x con correcciones y seguridad, 6.0.x como estable heredada y 5.1.x sin soporte. La escala global llega desde Stack Overflow 2025, con 37.341 respuestas de personas que influyen o avalan compras tecnológicas. La municipalidad necesita una herramienta abierta que el área de sistemas pueda instalar, respaldar y explicar ante cada cambio de estado. Un reclamo cerrado sin archivo final vuelve a abrirse en la primera reunión de vecinos.

Cómo funciona por dentro

El flujo mínimo tiene seis pasos. Primero, mesa de entradas o servicios públicos crea un proyecto por área o programa. Segundo, carga una petición con tipo, barrio, calle, prioridad, foto y responsable. Tercero, Redmine guarda issue, usuario, estado, historial y archivos asociados. PostgreSQL puede guardar esos registros cuando se elige esa base para la instalación. Cuarto, roles y permisos definen quién ve, edita, asigna o cierra. La guía de roles explica que cada rol reúne permisos y puede variar por proyecto. Quinto, el flujo de estados controla pasos como recibido, asignado, en ejecución, observado y cerrado. Sexto, el backup copia base, archivos adjuntos y configuración; la prueba restaura una obra completa y abre historial, foto inicial y archivo de cierre. Redmine recibe tickets, usuarios, estados, archivos y comentarios. Entrega listas, calendario, actividad, documentos y reportes por proyecto. El issue tracking setup ordena trackers, estados, prioridades y flujos. El almacenamiento conserva fotos y actas. Sistemas administra servidor, actualizaciones, roles y respaldo. Obras consulta tablero y cierra con evidencia.

Qué se instala o configura primero

La pila inicial puede ser Redmine 7, PostgreSQL 17, Nginx o Caddy, correo saliente, almacenamiento persistente de adjuntos, backup diario y usuarios por grupos. La guía general reúne administración de proyectos, usuarios, grupos, roles, issue tracking, campos personalizados y tareas de mantenimiento. El costo mensual de un piloto municipal chico puede ubicarse entre USD 30 y USD 90, entre ARS 45.000 y ARS 135.000 al dólar oficial de venta de ARS 1.500. El rango cubre servidor, base, correo, archivos, monitoreo y copia externa. Relevamiento de áreas, migración de planillas y capacitación quedan como horas de proyecto. El primer entregable verificable es un proyecto de obras con diez reclamos reales, cuatro roles, cinco estados y una exportación de cierre. UMSA puede ayudar a configurar el flujo y la prueba cuando el municipio necesita que cada cambio tenga usuario, hora y archivo.

Dónde se rompe y cómo probarlo

El primer riesgo aparece con estados demasiados abiertos. El indicador es una tarea que salta de recibida a cerrada sin responsable. La prueba es crear una petición y bloquear el cierre hasta adjuntar foto o acta final. El segundo riesgo aparece con permisos copiados entre áreas. El indicador es un usuario de arbolado que edita obras de alumbrado. La prueba es asignar roles por proyecto y buscar el mismo issue con dos cuentas. El tercer riesgo aparece con adjuntos fuera del backup. El indicador es una base restaurada que muestra reclamos sin fotos. La guía de backup y restore separa base de datos, archivos y configuración. La prueba restaura los tres componentes en otra máquina. El cuarto riesgo aparece con correo saliente roto. El indicador es una tarea asignada que nadie recibió. La prueba es enviar un caso de ensayo, medir recepción y dejar registro en el historial del issue. El cierre sirve cuando el IT manager puede abrir una obra y mostrar pedido, cambio de estado, responsable, archivo final y backup probado. La segunda prueba mira reportes. Una semana de reclamos debe salir por barrio, área, estado y responsable, con archivos descargables y fecha de última copia. Cuando esa exportación no aparece, la reunión vuelve a depender de memoria y capturas sueltas.

Para seguir leyendo