Módulos SaaS y plan gating

Módulos SaaS y plan gating

Qué es

El sistema de módulos SaaS controla qué funcionalidades puede usar cada organización según su plan de suscripción. Cada módulo (racks, network-maps, network-management) corresponde a un conjunto de URLs y endpoints. El gating se aplica en tiempo de request: si la org no tiene el módulo activo, la petición es bloqueada con HTTP 403 antes de llegar al view.

Por qué existe

CreaRack-Pro tiene distintos niveles de suscripción (starter, pro, custom). El gating por módulos permite activar o desactivar funcionalidades completas por organización sin cambiar código ni desplegar ramas distintas, y soporta módulos incluidos por plan y módulos à la carte.

Componentes

SaaSModule (core/models.py) — Registro de módulos gateables. Campos clave: slug, is_core (activo siempre), url_prefixes (metadato; el mapeo real vive en module_registry.py).

Plan (core/models.py) — Tier (starter, pro, custom). M2M con SaaSModule define módulos base del plan.

Organization.extra_modules (core/models.py) — M2M que almacena módulos efectivos de la org. Unión materializada: plan + à la carte. get_active_modules() devuelve set de slugs: todos los is_core=True + slugs en extra_modules.

module_registry.py (core/module_registry.py) — Diccionario URL_TO_MODULE que mapea prefijos URL a slugs. resolve_module(path) con longest-prefix-match. is_exempt(path) para auth/admin/static/health.

ModuleGatingMiddleware (core/middleware/module_gating.py) — Middleware tras AuthenticationMiddleware e ImpersonationMiddleware. Evalúa por request: (1) exento → pasa, (2) no autenticado → pasa (lo gestiona login_required), (3) superusuario → pasa con _active_modules = None, (4) org inactiva/deleted → 403 con disable_reason, (5) resolve_module(path) + check contra _active_modules → 403 JSON (en /api/*) o render errors/module_disabled.html.

Flujos

Gating en request: middleware resuelve módulo de la URL, coteja contra org.get_active_modules(), bloquea o permite. El resultado queda en request._active_modules para uso posterior (p.ej. core/admin.py).

Signup: core/api/signup.py crea org con plan starter en transacción atómica. Sincroniza extra_modules con unión de PKs de módulos is_core=True y PKs de plan.modules. La org arranca con el conjunto correcto sin paso posterior.

Toggling extra_modules: módulos del plan se auto-sincronizan vía admin (señal post_save o acción explícita). Los à la carte se añaden/eliminan directamente. El cálculo es dinámico en cada request, sin reinicio.

Related

• entity--core--model--saasmodule
• entity--core--model--plan
• entity--core--model--organization

Véase también

• [[entity—core—model—saasmodule]]
• [[entity—core—model—plan]]
• [[entity—core—model—organization]]