Contexto de autorização
A identidade, sua associação ao tenant e a função selecionada determinam o contexto de trabalho. Uma localização de Repository não substitui essas verificações. Uma conta ativa pode ter uma associação inativa; uma função visível não concede automaticamente todas as permissões. O servidor verifica a autoridade atual em cada ação e pode rejeitar uma operação anteriormente disponível.
Não confunda acesso ao Administrator com a identidade mestra única da plataforma. A isenção de cota do DovaAI para o superusuário exige identidade persistida, associação ativa e função de plataforma selecionada. Ela não é concedida a todos os administradores nem pela coincidência de um endereço de e-mail. A disponibilidade do provedor e os controles de autorização continuam válidos.
Revisar uma ação
| Objetivo | O que verificar |
|---|---|
| Consultar | Tenant, associação e permissão de leitura do módulo ou objeto |
| Editar | Permissão de alteração, versão atual e estado editável |
| Publicar | Rascunho salvo, dependências e permissão de publicação |
| Executar | Permissão de execução, plano, runtime, capacidade e Connections |
| Excluir ou limpar | Escopo, referências, bloqueios e confirmação atual |
A autorização não garante recursos disponíveis. Um plano válido também não concede permissões ausentes. Visualizar uma Session não significa poder executá-la; publicar um Workflow não ativa, por si só, um agendamento. Examine a operação específica em vez de deduzir privilégios pelo nome do módulo.
Investigar acesso negado
- Consulte sua identidade e tenant no contexto da conta atual.
- Confirme a função selecionada e a associação ativa.
- Identifique a ação concreta: leitura, edição, publicação, execução ou exclusão.
- Solicite ao administrador a revisão dessa autorização e de seu escopo, sem ampliar privilégios indiscriminadamente.
- Atualize a visualização após uma alteração aceita e confira novamente o recurso.
Em um exercício sintético, quem precisa apenas consultar Monitor deve revisar tentativas e resultados autorizados, não receber permissão para limpar Repository. Delegue a ação necessária, não um conjunto maior de permissões para esconder um problema de configuração.
Limites entre tenants e execução
Um worker público compartilha capacidade elegível; não compartilha objetos, conversas nem dados de outros tenants. Connections mantêm suas próprias restrições. O DovaAI consulta e recomenda dentro do escopo autorizado. Nunca cria, altera, publica, executa nem exclui artefatos, mesmo quando solicitado ou confirmado; uma instrução no chat não concede novas permissões.
Se identidade, tenant ou permissões mudarem durante uma operação, o contexto deve ser verificado novamente. Não reutilize uma confirmação antiga nem considere um botão oculto como único controle de segurança. A resposta do servidor e o estado aceito do objeto determinam o resultado. Preserve evidências de auditoria autorizadas, sem copiar credenciais nem informações de outro tenant.
Contexto de ambiente
Antes de usar este módulo, confirme Tenant, Domain e Environment no menu do usuário. O ambiente inicial é Development. As capacidades do módulo, Domain e ambiente se aplicam juntas; Production fica somente leitura sem autorização explícita. Mudar o seletor não transfere artefatos nem publica ou executa seus dados. Consulte ambientes e recuperação e promoção entre ambientes.
Permissões de ambiente
A autorização combina permissões do módulo, acesso ao Domain e capacidades do ambiente. O catálogo atual contém 23 permissões de ambiente: etl.environments.view, etl.environments.{development,test,stage,production}.{view,edit,publish,run,runtime.manage}, etl.environments.promote e etl.environments.runtime.manage. Permissões globais de leitura e Runtime mantêm seu escopo explícito; uma permissão de um ambiente não concede acesso a todos os outros. Administrar um módulo não substitui essas capacidades.
ETL Developer pode trabalhar em Development, Test e Stage e não tem acesso a Production por padrão. Release Manager pode revisar os quatro ambientes e publicar em Test, Stage e Production para promoções autorizadas; isso não concede edição nem execução em Production. A promoção mantém preview, dependências publicadas exatas e aprovação explícita de Production. Funções personalizadas podem conceder as capacidades necessárias por ambiente. A identidade do usuário não é duplicada por ambiente; confira a função ativa, associação e permissões efetivas.
Editores de Mapping, Session e Workflow de Production permanecem somente leitura: versões aceitas chegam pela promoção. Configurar Connections existentes ou novas de Production é uma capacidade separada que exige etl.connections.manage e etl.environments.production.edit; não libera esses três editores nem Connections legacy somente leitura.