Modelo de permisos

Quién puede subir qué, y cómo se resuelve. Por privacidad esta página documenta el modelo; los correos asignados se gestionan en datalab.planitone.co/operaciones/responsables.

Roles

Rol	Alcance
`admin-datalab` / `admin`	Control total: catálogo, schemas, asignaciones, anular cargas. Puede subir cualquier operación.
`responsable-datalab`	Subir información en las operaciones que tenga asignadas.
(sin rol)	Solo lectura pública de dashboards.

Los roles viven en usuarios/{emailKey}/roles (o roles_map). El emailKey es el correo con puntos reemplazados por guiones bajos: persona@unitropico.edu.co → persona@unitropico_edu_co.

Resolución de acceso a una operación

¿isAdmin()? ────────────────────────────► SÍ ⇒ puede subir
     │ no
     ▼
¿Existe override /responsables/operaciones/{OP_ID}?
     │ sí                                   │ no
     ▼                                      ▼
¿Su email está en el override?        ¿Su email está en
     │ sí        │ no                 /responsables/areas/{AREA_ID}?
     ▼           ▼                          │ sí        │ no
  PUEDE       NO PUEDE                      ▼           ▼
  SUBIR       (aunque sea del área)      PUEDE        NO PUEDE

El override REEMPLAZA, no suma. Si una operación tiene override, los responsables del área quedan excluidos salvo que se agreguen explícitamente al override. Al crear un override, incluye también al responsable del área si debe conservar acceso.

Estructura en RTDB

/DataLab/config/responsables/
  areas/
    SECRETARIA_GENERAL/
      secretariageneral@unitropico_edu_co: true
  operaciones/
    CARAC_GRAD_MENSUAL/            ← override: SOLO estos correos
      secretariageneral@unitropico_edu_co: true
      sneydercedeno_es@unitropico_edu_co: true

Formato: los correos son las claves del objeto (con .→_) y el valor es true. El código de autorización debe leer Object.keys(), nunca Object.values() — ese fue un bug real que dejaba fuera a todos los responsables en varias vistas.

Cobertura actual EN VIVO

Conteo de correos asignados (sin exponer cuáles).

Cargando…

Buenas prácticas

Prefiere asignar por área; usa override por operación solo cuando una op la reporta alguien distinto al área.
Si una op FULL se queda sin responsable resoluble, nadie puede subirla — la auditoría interna lo marca como crítico.
Cambios de responsable: gestión en /operaciones/responsables; efecto inmediato (el wizard consulta RTDB en cada carga).