You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Historia de usuario
Como administrador de un proyecto, quiero elegir qué módulos (Vault, Open Report, State IaC) están activos en ese proyecto, para que el proyecto solo exponga las herramientas que realmente necesita.
Contexto
Cierra la jerarquía Organization > Project > Module. Depende de la Issue 3 (Project Settings, nueva sección "Modules") y de la Issue 2 (selector de proyecto activo, necesario para saber sobre qué proyecto aplicar el gate en cada request).
Criterios de aceptación
Nueva relación ProjectModule { projectId, moduleKey, enabled, updatedAt }, usando como moduleKey los mismos valores de PERMISSION_SECTIONS (vault | openreport | stateiac) para no duplicar el catálogo.
En Project Settings, sección "Modules": toggle on/off por módulo, disponible para el admin del proyecto.
La navegación (topbar/nav lateral) oculta los módulos deshabilitados para el proyecto activo.
Cada ruta y endpoint del módulo (/vault, /open-report, /pulumi-state, y sus /api/* correspondientes) verifica que el módulo esté habilitado para el proyecto activo, además del permiso de rol ya existente — acceso directo por URL a un módulo desactivado devuelve 403/redirect, no solo se oculta en el menú.
Desactivar un módulo no borra sus datos: solo bloquea el acceso mientras esté desactivado; al reactivarlo, los datos siguen ahí.
Solo el admin del proyecto puede cambiar qué módulos están activos (mismo nivel de permiso que la Issue 3).
Notas técnicas
Centralizar el check en un helper tipo isModuleEnabled(project, moduleKey), análogo a can(), para no repetir la lógica en cada +page.server.ts/+server.ts.
El guard necesita el "proyecto activo" en el servidor, no solo en el cliente — depende de que la Issue 2 lo exponga vía cookie/locals en el load de cada ruta.
No hace falta forzar un mínimo de módulos activos; si el admin los desactiva todos, el proyecto simplemente queda sin herramientas visibles (no es un estado de error).
Fuera de alcance
Configuración propia de cada módulo dentro del proyecto (mencionado en el planteamiento original) — se aborda módulo a módulo en issues futuras, una vez esté el on/off.
Historia de usuario
Como administrador de un proyecto, quiero elegir qué módulos (Vault, Open Report, State IaC) están activos en ese proyecto, para que el proyecto solo exponga las herramientas que realmente necesita.
Contexto
Cierra la jerarquía Organization > Project > Module. Depende de la Issue 3 (Project Settings, nueva sección "Modules") y de la Issue 2 (selector de proyecto activo, necesario para saber sobre qué proyecto aplicar el gate en cada request).
Criterios de aceptación
Notas técnicas
Centralizar el check en un helper tipo isModuleEnabled(project, moduleKey), análogo a can(), para no repetir la lógica en cada +page.server.ts/+server.ts.
El guard necesita el "proyecto activo" en el servidor, no solo en el cliente — depende de que la Issue 2 lo exponga vía cookie/locals en el load de cada ruta.
No hace falta forzar un mínimo de módulos activos; si el admin los desactiva todos, el proyecto simplemente queda sin herramientas visibles (no es un estado de error).
Fuera de alcance
Configuración propia de cada módulo dentro del proyecto (mencionado en el planteamiento original) — se aborda módulo a módulo en issues futuras, una vez esté el on/off.