0013. Catálogo inicial de módulos y acciones (seed de navegación)¶

Estado: Propuesto Fecha: 2026-09-08 Autor: Duval Alcivar Módulo(s) afectado(s): svc-identidad (core_sigfa), frontend (React 18)

Contexto¶

El ADR 0006 (y el transversal 0013) definen el modelo de navegación: cat_aplicaciones, cfg_modulos, cfg_menu, cfg_menu_acciones. Las tres últimas son por empresa (empresa_id + RLS): cada empresa tiene su propio árbol de módulos y puede crear módulos específicos. Pero un sistema nuevo no puede arrancar en blanco: necesita un catálogo inicial de qué módulos, páginas y acciones tiene cada aplicación.

Ese catálogo inicial es la plantilla que se clona a cada empresa en el alta (ADR 0016). Este ADR define: (1) las aplicaciones del catálogo global, (2) la estructura de plantilla por aplicación (módulos → páginas → acciones), y (3) el mecanismo para clonarla a una empresa.

Decisión¶

1. Aplicaciones del catálogo global (`cat_aplicaciones`)¶

cat_aplicaciones contiene tres aplicaciones (no se contrata core, se aprovisiona siempre):

codigo	nombre	Se contrata	Rol
`core`	Core Sigfa	no (siempre)	núcleo de plataforma: módulos de administración de identidad/permisos
`erp`	ERP Sigfa	sí	módulos de operación (rrhh, inventario, contabilidad…)
`crm`	CRM SigfaPro	sí	módulos comerciales (promotores, ventas…)

La empresa decide qué contrata (rel_empresa_aplicacion, ADR 0006); core se clona siempre porque es la administración de la propia tenencia (usuarios, permisos). En el panel se agrupan en Core / ERP / CRM (ADR 0010).

2. Forma de la plantilla¶

Cada aplicación tiene una plantilla de navegación versionada en el repositorio de svc-identidad (migraciones de datos, no tablas espejo):

cfg_modulos — módulos de la aplicación.
cfg_menu — páginas por módulo (máx. 3 niveles, padre_id).
cfg_menu_acciones — acciones por página (crear, editar, eliminar, ver, más las específicas del dominio).

Convenciones de códigos (estables, no se renombra una vez publicado):

Módulo: rrhh, inventario, contabilidad, produccion, promotores, ventas, permisos, tickets…
Página: codigo corto del nodo en su módulo/padre (nomina, registro, vacaciones…).
Acción: crear, editar, eliminar, ver + específicas (subir_archivo, aprobar, exportar, conciliar…).

3. Contenido inicial de la plantilla¶

Core → módulo permisos (administración de la tenencia):

cfg_menu (permisos)
├── usuarios            (nivel 1)
│   ├── lista           ({acciones: ver, crear, editar, eliminar})
│   └── detalle         ({acciones: ver, editar})
├── permisos            (nivel 1)
│   └── asignar         ({acciones: ver, asignar})
└── empresas            (nivel 1)          ← solo visible para root de plataforma
    ├── lista           ({acciones: ver, crear, editar, eliminar})
    └── aplicaciones    ({acciones: ver, editar})

ERP → módulos produccion, rrhh, inventario, contabilidad (ejemplo detallado de rrhh, igual plantilla para los demás):

cfg_modulos → rrhh
cfg_menu (rrhh)
├── nomina              (nivel 1)
│   ├── registro        ({acciones: ver, crear, editar, eliminar, aprobar})
│   └── vacaciones      ({acciones: ver, crear, editar, eliminar})
└── asistencia          (nivel 1)
    ├── marcaciones     ({acciones: ver, crear, editar, eliminar})
    └── reportes        (nivel 2)
        └── consolidado (nivel 3, {acciones: ver, exportar})

CRM → módulos promotores, ventas:

cfg_modulos → promotores
cfg_menu (promotores)
├── rutas               ({acciones: ver, crear, editar, eliminar})
└── metas               ({acciones: ver, crear, editar, eliminar})

cfg_modulos → ventas
cfg_menu (ventas)
├── cotizaciones        ({acciones: ver, crear, editar, eliminar, aprobar})
└── pedidos             ({acciones: ver, crear, editar, eliminar, anular})

Las acciones por página definen lo que puede ejecutarse; el permiso para cada acción se declara en cat_permisos (ADR 0014) y se otorga por usuario con rel_usuario_menu_accion (ADR 0015).

4. Mecanismo de clonado (plantilla → empresa)¶

En el alta transaccional de la empresa (ADR 0016, mismo flush), se clona la plantilla a la empresa en una sola operación:

-- por cada aplicación contratada (core siempre + erp/crm según contrato)
INSERT INTO core.identidad.cfg_modulos
    (empresa_id, aplicacion_id, codigo, nombre, descripcion, icono, orden)
SELECT
    :nueva_empresa, m.aplicacion_id, m.codigo, m.nombre, m.descripcion,
    m.icono, m.orden
FROM app_plantilla.plantilla_modulos m
WHERE m.aplicacion_id IN (:aplicaciones_de_la_empresa);
-- idem para cfg_menu (preservando padre_id con un mapeo de UUIDs)
-- e idem para cfg_menu_acciones

Las plantillas viven en código versionado del servicio (data-import / migraciones), en un esquema app_plantilla de solo lectura; no son tablas de negocio por empresa.
El clon genera UUIDs nuevos por fila y conserva codigo, nivel, orden, ruta_frontend y las acciones de la plantilla.
Una vez clonada, la empresa puede personalizar (ocultar, renombrar, crear módulos propios); el clon solo ocurre en el alta.
Un cambio posterior de plantilla no se propaga a empresas existentes (cada empresa edita su árbol); se propaga vía release manual o script de migración si SIGFA lo requiere (p. ej. añadir una página estándar).

5. Endpoints (gestión del catálogo)¶

La persona de plataforma edita el árbol de la empresa con los endpoints de gestión (ADR 0009) y el catálogo base con un CRUD solo de plataforma (bajo /api/v1, ADR transversal 0016):

Endpoint	Método	Qué hace
`/api/v1/catalogos/aplicaciones`	GET	listar aplicaciones del catálogo global
`/api/v1/catalogos/plantilla?app=erp`	GET	ver la plantilla de una aplicación
`/api/v1/catalogos/plantilla`	PUT	actualizar la plantilla base (código versionado)

Alternativas descartadas¶

Arrancar la empresa con el árbol vacío — inutilizable el día 1; vulnera la regla "alta operativa desde el primer momento" (ADR 0008).
Tabla única cfg_modulos global (sin clón por empresa) — los módulos de cada empresa podrían divergir; el aislamiento por empresa_id (RLS) exige filas por empresa.
Plantillas duplicadas en el frontend — la plantilla es dato del backend; el frontend solo la muestra (ADR 0006/0010 transversales).
Esquema por empresa dentro de core_sigfa — la tenencia usa RLS con empresa_id (ADR transversal 0012), no esquemas separados.

Consecuencias¶

Cada alta de empresa genera su árbol base completo (módulos → páginas → acciones) en la misma transacción, sin trabajo manual.
Las aplicaciones disponibles son core (siempre), erp y crm (contratadas); la grilla del panel (ADR 0010) las agrupa en Core / ERP / CRM.
Las acciones por página alimentan el catálogo de permisos (ADR 0014) y la asignación fina por usuario (ADR 0015).
La plantilla es versionada; tocar la plantilla base no toca a las empresas existentes.
Resuelto: pendiente 0013 del README (catálogo inicial de módulos y acciones por aplicación).

Complementa el ADR 0006 (adopción del modelo) y el transversal 0013 (DDL). La clonación transaccional se define en el ADR 0016; los permisos derivados de estas acciones en los ADR 0014 y 0015.