Acceso · S-PLAN

Permisos

Quién puede hacer qué, sobre qué meta y con qué garantía. S-PLAN combina un rol global con una asignación por meta, y apoya el control efectivo en las reglas de la base de datos —no en la interfaz—.

Las tres capas

1

Visibilidad en la interfaz

Clases CSS que muestran u ocultan controles según el rol. Mejora la experiencia —nadie ve botones que no puede usar— pero no protege nada: es código que corre en el navegador del usuario.

2

Comprobaciones en la aplicación

Validaciones antes de escribir: que el ciclo esté abierto, que la ruta de la meta coincida con indices_metas, que el usuario tenga el rol requerido. Evitan errores honestos y datos corruptos; tampoco detienen a quien opere fuera de la interfaz.

3

Reglas de seguridad de Firebase

La única capa que se aplica del lado del servidor y que decide de verdad quién lee y quién escribe cada nodo. Cualquier permiso que importe debe estar expresado aquí.

Consecuencia de diseño. S-PLAN es una aplicación de cliente que habla directo con Firebase (ver Infraestructura). No existe un backend intermedio que pueda filtrar peticiones: por eso las reglas de la base son el control de acceso, y el resto es ergonomía.

Asignación de metas a responsables

El rol responsable-s-plan habilita reportar; sobre qué se reporta lo define un índice aparte:

S-PLAN/metas_responsables/{metaId} = { "R32": true }

Y la relación entre ese código y una persona vive en el directorio responsables/{Rn}, con su nombre, cargo, área y correo institucional. Para saber qué metas le corresponden a quien inició sesión hay que enlazar correo → código de responsable → metas.

El puente correo ↔ código es frágil. El árbol del PDI guarda códigos (R79), el directorio de usuarios se indexa por correo saneado, y el campo responsable de las acciones puede llegar de Excel con espacios o saltos de línea ("R79\r\n"). Normaliza siempre antes de comparar; una coincidencia fallida deja a un responsable sin ver sus propias metas.

Qué es público y qué no

Información institucional

  • Estructura del plan: ejes, programas, proyectos y metas.
  • Avance y ponderación de cada meta.
  • Inversión reportada y contratos asociados.
  • Alertas globales (su lectura es anónima por diseño).

Debe protegerse

  • responsables/{Rn}: nombre, cargo, correo personal y documento.
  • Correos y autoría en evidencias y conversaciones.
  • Bandejas personales de notificación.
  • Cualquier escritura sobre el plan.

La API que alimenta esta documentación aplica ese criterio: publica la estructura y las cifras agregadas, y del lado personal solo expone cuántos responsables tiene una meta.

Verificación de permisos

Preguntas útiles al revisar el estado del control de acceso:

  1. ¿La escritura sobre S-PLAN/ejes/** exige rol de administrador o responsable, o basta con estar autenticado?
  2. ¿Un responsable puede escribir en metas que no tiene asignadas?
  3. ¿La carga de evidencias valida el ciclo abierto también en las reglas, o solo en la interfaz?
  4. ¿responsables/** es legible sin sesión?
  5. ¿notificaciones/s-plan/personal/{correo} es legible solo por su destinatario?
  6. ¿S-PLAN/config/ciclo_carga y S-PLAN/cortes están restringidos a administración?
Recomendación de operación: cuando la respuesta a alguna de estas preguntas no sea evidente, revísala directamente en las reglas del proyecto Firebase antes de asumirla. La interfaz no es evidencia de lo que la base permite.

Buenas prácticas de administración

Rol mínimo

Asigna responsable-s-plan salvo que la persona realmente administre el plan. Recuerda que cualquier rol con “admin” en el nombre abre el modo administrador general.

Revisa por ciclo

Al abrir cada ciclo, valida que las asignaciones de metas_responsables siguen vigentes: los cambios de dependencia no se propagan solos.

Retira accesos

Cuando alguien deja la Universidad, quita su roles_map. El histórico de lo que cargó se conserva —y debe conservarse— en las evidencias.

Deja rastro

Las decisiones importantes (override de avance, regeneración de un snapshot) deben quedar justificadas en el campo de motivo o en la descripción, no solo en la memoria de quien las hizo.

Relacionado: Roles · Autenticación · Datos personales.