Documentación · DataLab

Roles

En DataLab, lo que puedes hacer depende de tu rol: desde control total de la suite hasta subir información solo en las operaciones que tengas asignadas. Aquí están los roles, su alcance y dónde viven.

Los roles del DataLab

Un usuario puede tener uno o varios roles. Los tres roles administrativos habilitan el mismo poder operativo dentro de DataLab; responsable-datalab se limita a lo que tiene asignado, y quien no tiene rol conserva la lectura pública de los dashboards.

RolAlcancePuede subir
admin global Control total de toda la suite PlanItOne; puede todo en DataLab. Cualquier operación
admin-datalab DataLab Administra DataLab: catálogo, schemas, asignaciones, aprobar/rechazar, anular cargas y procesar. Cualquier operación
admin-planeacion Planeación Rol administrativo de Planeación con acceso equivalente en DataLab. Cualquier operación
responsable-datalab acotado Sube información en las operaciones que tenga asignadas. Solo lo asignado
(sin rol) público Lectura pública de dashboards. No sube
Poder equivalente, foco distinto. admin, admin-datalab y admin-planeacion pueden subir cualquier operación; el rol elegido refleja el ámbito de la persona (toda la suite, la administración del módulo o la Oficina de Planeación), no una diferencia de permisos dentro de DataLab.

Dónde viven los roles

Los roles se guardan en el nodo del usuario, en usuarios/{emailKey}, con cualquiera de estas dos formas:

roles_map

Un objeto {rol:true}, por ejemplo {"admin-datalab":true}. Formato preferido para consultar por clave.

roles

Un arreglo de cadenas, por ejemplo ["responsable-datalab"]. Forma alternativa que el sistema también reconoce.

El emailKey

La clave del usuario es su correo con los puntos reemplazados por guion bajo, porque las claves de Firebase RTDB no admiten el carácter .:

CorreoemailKey
persona@unitropico.edu.copersona@unitropico_edu_co
Ojo con la conversión. El emailKey reemplaza todos los puntos, no solo el del dominio. Si construyes la clave a mano y dejas algún ., no encontrarás al usuario y su rol quedará invisible. Es la misma convención que usan las asignaciones de responsables en el modelo de permisos.
Espacio para screenshot Nodo de usuario en RTDB Un registro usuarios/{emailKey} mostrando roles_map y su correspondencia con el correo.

Del rol al acceso real

Tener un rol es el primer paso, pero para responsable-datalab el acceso a una operación concreta se resuelve además según sus asignaciones (por área y overrides por operación). Ese detalle vive en su propia página:

1

Autenticación

La persona inicia sesión y el sistema identifica su correo. Ver Autenticación.

2

Rol

Se leen sus roles desde usuarios/{emailKey} (roles_map o roles).

3

Resolución de acceso

Si es administrador, puede subir todo. Si es responsable-datalab, se comprueban sus asignaciones para esa operación. Ver Modelo de permisos.

La gestión de qué correo tiene qué rol es una tarea administrativa. Para el alcance operativo día a día (quién sube cada cosa), la fuente de la verdad es el modelo de permisos.