Contexto de autorización
La identidad, su membresía en el tenant y el rol seleccionado determinan el contexto de trabajo. La ubicación de Repository no reemplaza esas comprobaciones. Una cuenta activa puede tener una membresía inactiva; un rol visible no concede automáticamente todos los permisos. El servidor comprueba la autoridad actual para cada acción y puede rechazar una operación que antes estaba disponible.
No confundas acceso a Administrator con la identidad maestra única de la plataforma. La exención de cuota de DovaAI del superusuario requiere la identidad persistida, membresía activa y rol de plataforma seleccionado. No se concede a todos los administradores ni por coincidir un correo. Los controles de proveedor y autorización siguen vigentes.
Revisar una acción
| Objetivo | Qué revisar |
|---|---|
| Consultar | Tenant, membresía y permiso de lectura del módulo u objeto |
| Editar | Permiso de cambio, versión actual y estado editable |
| Publicar | Borrador guardado, dependencias y permiso de publicación |
| Ejecutar | Permiso de ejecución, plan, runtime, capacidad y conexiones |
| Eliminar o purgar | Alcance, referencias, bloqueos y confirmación actual |
La autorización no garantiza recursos disponibles. Un plan válido tampoco concede permisos ausentes. Ver una Session no significa que pueda ejecutarse, y publicar un Workflow no activa por sí solo un horario.
Procedimiento para acceso denegado
- Consulta tu identidad y tenant desde la cuenta actual.
- Confirma el rol seleccionado y la membresía activa.
- Identifica la acción concreta: lectura, edición, publicación, ejecución o eliminación.
- Pide al administrador que revise esa autorización y su alcance, sin ampliar privilegios de forma indiscriminada.
- Actualiza la vista tras un cambio aceptado y vuelve a comprobar el recurso.
Para un ejercicio sintético, una persona que solo consulta Monitor debe revisar intentos y resultados autorizados, no recibir permisos para purgar Repository. Delega la acción necesaria, no un conjunto mayor para ocultar un fallo de configuración.
Límites entre tenants y ejecución
Un worker público comparte capacidad elegible; no comparte objetos, conversaciones ni datos de otros tenants. Las Connections mantienen sus propias restricciones. DovaAI consulta y recomienda dentro del alcance autorizado. Nunca crea, modifica, publica, ejecuta ni elimina artefactos, aunque lo solicites o confirmes; una instrucción del chat no concede permisos nuevos.
Si cambian identidad, tenant o permisos durante una operación, el contexto debe volver a comprobarse. No reutilices una confirmación antigua ni interpretes un botón oculto como único control de seguridad. La respuesta del servidor y el estado aceptado del objeto determinan el resultado. Conserva evidencia de auditoría autorizada sin copiar credenciales o información de otro tenant.
Contexto de entorno
Antes de utilizar este módulo confirma Tenant, Domain y Environment en el menú de usuario. El entorno inicial es Development. Las capacidades del módulo, el Domain y el entorno se aplican juntas; Production queda de solo lectura sin autorización explícita. Cambiar el selector no mueve artefactos ni publica o ejecuta sus datos. Consulta entornos y recuperación y promoción entre entornos.
Permisos de entorno
La autorización combina permisos del módulo, acceso al Domain y capacidades del entorno. El catálogo actual contiene 23 permisos de entorno: etl.environments.view, etl.environments.{development,test,stage,production}.{view,edit,publish,run,runtime.manage}, etl.environments.promote y etl.environments.runtime.manage. Los permisos globales de lectura y Runtime conservan su alcance explícito; un permiso de un entorno no concede acceso a todos los demás. Administrar un módulo no sustituye estas capacidades.
ETL Developer puede trabajar en Development, Test y Stage y no tiene acceso a Production por defecto. Release Manager puede revisar los cuatro entornos y publicar en Test, Stage y Production para promover versiones autorizadas; no obtiene edición ni ejecución de Production. La promoción conserva el preview, las dependencias publicadas exactas y la aprobación explícita de Production. Los roles personalizados permiten asignar las capacidades necesarias por entorno. La identidad del usuario no se duplica por ambiente; verifica el rol activo, la membresía y sus permisos efectivos.
Los editores de Mapping, Session y Workflow de Production permanecen de solo lectura: las versiones aceptadas llegan mediante promoción. Configurar Connections existentes o nuevas de Production es una capacidad separada que exige etl.connections.manage y etl.environments.production.edit; no habilita edición de esos tres tipos ni modifica Connections legacy de solo lectura.