Acceso · PolariScore

Permisos

Quién puede hacer qué, sobre qué política y con qué garantía. PolariScore combina un rol global con una asignación por política, y el control efectivo vive en las reglas de la base —no en la interfaz—.

Las tres capas

1

Visibilidad en la interfaz

Comprobaciones de rol que muestran u ocultan flujos completos. Mejoran la experiencia y evitan errores, pero no protegen nada: es código que corre en el navegador del usuario.

2

Comprobaciones en la aplicación

Validaciones antes de escribir: que exista la acción, que el archivo cumpla el formato, que la sesión esté activa. Evitan datos corruptos; no detienen a quien opere fuera de la interfaz.

3

Reglas de seguridad de Firebase

La única capa aplicada del lado del servidor. Es la que decide de verdad quién lee y quién escribe cada nodo.

Estado conocido de la capa 3. La base opera con una regla de línea base —usuario autenticado para lectura y escritura— sin un bloque específico para el subárbol de PolariScore. En la práctica esto significa que cualquier persona con sesión válida en la suite puede escribir en los nodos de PolariScore si opera fuera de la interfaz, aunque su rol no le muestre esas opciones. El gateado por rol es únicamente de interfaz.

Consecuencias de eso, ordenadas por lo que conviene atender primero:

  1. La configuración de correos de notificación es escribible por cualquier usuario autenticado.
  2. La ejecución reportada (seguimientos) y los estados de evidencia no están protegidos por rol.
  3. El directorio de responsables —que incluye documento y correo personal— es legible por cualquier sesión.

Ninguno de estos puntos es un incidente en curso: es la superficie de riesgo que conviene cerrar cuando se endurezcan las reglas. Documentarlo es el primer paso.

Asignación de responsables

El rol habilita cargar evidencias; sobre qué se carga depende de la política. La asignación vive en la propia política, como una lista de códigos separados por coma:

PolariScore/politicas/P-001 = {
  responsables:        "R136, YJ88WH",
  correos_responsables: "viceacademica@unitropico.edu.co"
}

Los códigos se resuelven contra el directorio (responsables/{Rn}) para mostrar nombre, cargo y área. A nivel de evidencia individual existe además id_responsable, que indica quién debe aportar ese soporte.

La asignación es informativa, no restrictiva. Al ser una cadena de texto y no un índice, la aplicación la usa para mostrar de quién es la política, pero no impide que un responsable cargue en una política que no le corresponde. Si esa restricción se vuelve necesaria, hay que convertirla en un índice consultable por las reglas.

Qué es público y qué no

Información institucional

  • Las políticas, sus objetivos y sus acciones.
  • El cumplimiento y su evolución en el tiempo.
  • Los indicadores, sus hitos y su programación.
  • Los documentos oficiales de cada política.

Debe protegerse

  • responsables/{Rn}: nombre, cargo, correo personal y documento.
  • Los archivos de evidencia y quién los cargó.
  • Las observaciones, que pueden contener juicios sobre el trabajo de una persona.
  • Toda escritura sobre políticas, seguimientos y evidencias.

La API que alimenta esta documentación aplica ese criterio: publica estructura y cifras agregadas, y del lado personal solo expone conteos —nunca identidades, URLs de archivos ni observaciones—.

Permisos sobre los archivos

Los archivos viven en Firebase Storage bajo dos prefijos:

PrefijoContenido
PlanItOne/PolariScore/evidencias/…Soportes de las acciones, organizados por acción, evidencia y ciclo.
PolariScore/politicas/{id}/documentos/…Documentos oficiales de la política.
Las URL de descarga llevan token y no caducan. Una vez compartido el enlace de un archivo, sigue siendo accesible aunque la persona pierda el acceso a la aplicación. Trátalos como enlaces permanentes: no los pegues en canales abiertos.

Verificación de permisos

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

  1. ¿La escritura sobre PolariScore/politicas/** exige rol de administrador?
  2. ¿Puede un responsable modificar seguimientos, que es la ejecución reportada?
  3. ¿Está responsables/** restringido, siendo que contiene documentos de identidad?
  4. ¿PolariScore/config/notif_emails solo lo escriben administradores?
  5. ¿Las reglas de Storage limitan la lectura de las evidencias a usuarios autenticados?
  6. ¿Existe alguna regla que impida borrar un nodo completo de política por error?
Recomendación de operación: revisa estas preguntas directamente en las reglas del proyecto Firebase antes de darlas por resueltas. La interfaz no es evidencia de lo que la base permite.

Buenas prácticas de administración

Rol mínimo

Asigna responsable-polariscore salvo que la persona realmente administre el seguimiento de políticas.

Retira accesos

Cuando alguien deja la Universidad, quita su roles_map. Lo que cargó se conserva —y debe conservarse—.

Deja rastro

Un rechazo de evidencia sin motivo escrito obliga a adivinar. Las observaciones son parte del expediente.

Respalda antes de cargar

La carga masiva reemplaza nodos completos. Sin respaldo, no hay vuelta atrás.

Relacionado: Roles · Autenticación · Datos personales.