Directus 12 en cámaras: formularios, roles y salida
Un caso de cámara empresaria muestra cómo ordenar formularios, socios y permisos con Directus 12, PostgreSQL y una prueba de salida verificable.
Un formulario sin dueño bloquea la cuota antes de que tesorería cargue el pago. En una cámara empresaria de San Martín, cada alta de socio cruzaba planilla, mensaje y comprobante, con versiones distintas del mismo dato. Directus 12.1.1 entra como panel sobre PostgreSQL: guarda socios, formularios, roles y archivos con API REST o GraphQL. El lector va a ver cómo ordenar ese flujo y cómo probar la salida si el proveedor cambia.
Dónde se pierde el trámite antes del pago
El problema operativo aparece cuando una ficha de socio viaja por tres lugares. El tesorero ve una cuota impaga, administración ve una solicitud incompleta y sistemas ve un adjunto sin relación con el registro. Directus describe en su documentación una capa de acceso por roles, APIs instantáneas y modelado de datos sobre bases SQL. La cifra local del caso es chica y suficiente: 40 altas mensuales generan 40 formularios, 40 comprobantes y al menos 80 cambios de estado si cada solicitud pasa por carga y aprobación. La cifra global muestra por qué conviene apoyar esto en una base conocida: Stack Overflow 2025 lista SQL con 58,6% de uso y PostgreSQL con 55,6% entre bases de datos. El dato de mantenimiento también importa. La API pública de GitHub consultada para esta corrida muestra directus/directus con 36.460 estrellas, y la última versión registrada fue v12.1.1, publicada el 1 de julio de 2026. Ese número ayuda a medir actividad del proyecto antes de poner datos internos.
Cómo funciona por dentro Directus recibe una base PostgreSQL y expone colecciones.
Una colección socios guarda razón social, CUIT, estado, categoría y responsable. Una colección solicitudes guarda fecha, tipo de trámite, adjuntos y decisión. PostgreSQL conserva registros estructurados y auditoría; Directus entrega pantallas, API y control de acceso. El flujo tiene seis pasos. Primero, administración carga una solicitud desde el panel o un formulario público. Segundo, Directus valida campos obligatorios y permisos. Tercero, PostgreSQL guarda el estado y el usuario que modificó el registro. Cuarto, los adjuntos se guardan en almacenamiento configurado y quedan unidos al trámite. Quinto, tesorería consulta una vista filtrada por estado de cuota. Sexto, el backup copia base, archivos y variables de configuración; una prueba restaura un socio completo con su historial. Los roles son la parte delicada. La guía de seguridad de Directus advierte que los cambios de permisos alteran el control de acceso de todo el proyecto, por lo que solo administradores deben editar reglas sensibles. Un rol de carga crea solicitudes; un rol de revisión aprueba; un rol de tesorería lee cuotas; un rol técnico administra migraciones y backup.
Qué se instala o configura primero
La primera instalación puede correr en un VPS Linux con Docker, PostgreSQL 17, proxy HTTPS y backup externo. Para una cámara chica, el costo mensual de servidor, almacenamiento y monitoreo puede quedar entre USD 20 y USD 35, unos ARS 30.200 a ARS 52.850 al dólar oficial de venta consultado. Ese monto no incluye relevamiento, carga histórica ni soporte de usuarios. UMSA podría tomar un caso así con un entregable de dos semanas: modelo de datos, matriz de permisos, formulario de alta, tablero de estados y prueba de exportación CSV. La cámara conserva la base y la documentación; el equipo técnico conserva scripts de instalación, restauración y actualización. El primer entregable verificable es simple: crear un socio de prueba, adjuntar un comprobante, cambiar el estado, consultar la cuota y exportar todo a CSV. Si esa prueba sale, el sistema ya tiene una salida mínima para una mudanza futura.
Dónde se rompe y cómo probarlo
El primer riesgo aparece cuando los permisos quedan amplios. La señal es un usuario de carga que puede leer datos de todos los socios o editar estados de tesorería. La prueba crea usuarios de cada rol y ejecuta acciones permitidas y rechazadas, con captura de resultado. El segundo riesgo está en los adjuntos. La señal es un archivo visible en el servidor y ausente en el trámite. La prueba sube tres comprobantes, cambia un estado, restaura en otro ambiente y abre cada archivo desde el registro recuperado. El tercer riesgo aparece al actualizar versión. La señal es una extensión rota o una política qué cambia de comportamiento. La prueba clona base y archivos, actualiza primero en staging, revisa el changelog de Directus y ejecuta el flujo de alta completo. El cierre incómodo es operativo: si la cámara no puede exportar socios, pagos y adjuntos en una tarde, todavía depende de alguien más.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.