OpenProject 17.9 en cooperativas: obras, roles y backup
Un caso de cooperativa muestra cómo ordenar tareas, adjuntos y permisos de obra con OpenProject antes de perder el cierre semanal y su respaldo.
¿Quién puede cerrar una tarea de obra cuando la cuadrilla todavía debe subir fotos y mediciones? Una cooperativa eléctrica con internet rural puede perder el cierre semanal por una tarea marcada a destiempo. OpenProject 17.9.1 sirve para ordenar paquetes de trabajo, roles y adjuntos con una prueba de backup. Esta nota muestra el flujo de un caso anonimizado y qué revisar antes de copiarlo. ## Dónde se traba el cierre semanal OpenProject publicó la versión 17.9.1 el 1 de octubre de 2026, con correcciones sobre la barra lateral de paquetes de trabajo y acceso SSO en Chrome, según la release oficial. El dato chico importa: una pantalla que desaparece o un login que falla alcanza para frenar la carga de novedades de obra. La cifra global pone el caso en contexto. Stack Overflow 2026 ubica a PostgreSQL con 57,9 % de uso entre quienes respondieron sobre bases de datos, en su reporte de tecnología. OpenProject usa base de datos, archivos adjuntos y permisos; ese trío necesita respaldo y roles, no solo una lista de tareas. El gerente de una cooperativa eléctrica puede tener postes, planos, fotos y reclamos en el mismo cierre. La carpeta plástica con precintos sigue sobre la camioneta, pero la decisión de cerrar el trabajo queda en una pantalla compartida por oficina técnica, depósito y proveedor. El antagonista es el cierre manual del viernes.
Cómo funciona por dentro
El flujo tiene seis pasos. Primero, oficina técnica crea un proyecto por obra o tramo de red. Segundo, cada paquete de trabajo guarda tarea, responsable, fecha, estado, prioridad y adjuntos. Tercero, el proveedor externo carga fotos o comentarios en tareas autorizadas. Cuarto, un rol de coordinación cambia estados y otro rol solo consulta. Quinto, PostgreSQL guarda datos de proyectos, usuarios y auditoría; el sistema de archivos guarda adjuntos. Sexto, el backup toma base y archivos, y una restauración de prueba abre una obra real. La guía de instalación Docker de OpenProject describe el despliegue con contenedores. La aplicación recibe tareas, comentarios y adjuntos; PostgreSQL entrega estados y consultas; el almacenamiento guarda archivos; el proxy TLS publica acceso para usuarios internos o externos. La documentación de paquetes de trabajo muestra que la unidad operativa no es una nota suelta: es un registro con campos, historial y relación con otros trabajos. Cuando una cuadrilla sube fotos, el sistema debe conservar quién cargó, cuándo, en qué tarea y con qué permiso.
Qué se instala o configura primero
El primer entregable verificable es una obra piloto con diez paquetes de trabajo, dos roles internos, un proveedor externo y tres adjuntos recuperables. La pila mínima usa OpenProject 17.9.1, PostgreSQL 17, almacenamiento local con copia externa, proxy TLS y monitoreo de disco. El costo mensual de una instalación chica ronda USD 60 a USD 140 para servidor, almacenamiento y backup externo. Con dólar oficial vendedor a ARS 1535, equivale a ARS 92.100 a ARS 214.900 por mes, sin horas de carga inicial ni capacitación. El piloto puede quedar listo en una semana si la cooperativa ya tiene estados de obra definidos. UMSA puede acompañar este tipo de adopción en cooperativas y áreas de infraestructura: parametrizar roles, migrar tareas vivas y dejar una prueba de salida. El primer día no se mide por cantidad de pantallas; se mide por una tarea creada, aprobada, cerrada y restaurada. El tablero inicial debe mostrar cuatro columnas: tareas abiertas, tareas con adjuntos, tareas bloqueadas y tareas listas para cierre. Cada columna necesita un responsable visible y una fecha de revisión. Esa vista sirve para reunión corta de obra y para auditoría posterior, porque reduce la discusión a registros concretos del mismo proyecto. La guía de roles y permisos permite definir quién lee, comenta, edita o administra. La sección de backup aclara que una copia útil incluye base de datos y adjuntos.
Dónde se rompe y cómo probarlo
El primer riesgo aparece cuando todos tienen permiso para cerrar tareas. La señal es una obra marcada terminada sin foto final. La prueba crea un usuario proveedor, intenta cerrar una tarea y confirma que solo pueda comentar o adjuntar evidencia. El segundo riesgo aparece cuando los adjuntos quedan fuera del backup. La señal es una restauración con tareas visibles y fotos ausentes. La prueba toma una copia, la restaura en otro servidor y abre tres tareas con archivos cargados por usuarios distintos. El tercer riesgo aparece cuando cada área usa estados propios. La señal es una lista con "hecho", "cerrado", "ok" y "terminado" para la misma condición. La prueba define cuatro estados, migra diez tareas y rechaza cualquier cierre que no tenga responsable y fecha. El cierre queda en una acción: restaurá una obra piloto antes de sumar la segunda cuadrilla.
