Buscar K
Aparência
Controle de Acesso às Mesas
As Mesas são os containers do Horus, e desde 03/09 (DEVCOMP-1, v1.1.388) as duas naturezas seguem o mesmo modelo de acesso: nascem trancadas, e só mostram o que guardam depois de um acesso explícito. A diferença que continua fácil de errar é outra: o alcance de cada mesa. A Mesa de Dados trava quem constrói, no HorusDW e no HorusETL, não quem consome; um Dashboard publicado continua visível a quem tem acesso à Mesa de Aplicação, mesmo que a tabela por trás dele esteja numa Mesa de Dados fechada para aquele usuário. Entender essa separação evita tanto o susto de "por que ele não acha a tabela no HorusDW?" quanto o de "bloqueei a mesa de dados e o dashboard continua abrindo para ele".
Esta página é a fonte de verdade sobre como o acesso funciona em cada natureza de mesa, quem passa por cima do quê, e como Publicar, Lixeira e Writeback herdam essas mesmas regras.
🗄️ Duas naturezas, o mesmo modelo de acesso
Toda mesa é de uma de duas naturezas, e hoje as duas partem do mesmo estado:
| Mesa de Aplicação | Mesa de Dados | |
|---|---|---|
| O que guarda | Dashboards e Aplicações de BI | Tabelas e Dataflows do Data Warehouse |
| Modelo de acesso | Lista de permissão (allow-list) | Lista de permissão (allow-list) |
| Estado inicial | Nasce trancada | Nasce trancada |
| Quem vê por padrão | Ninguém, até receber acesso explícito | Ninguém, até receber acesso explícito |
| Como se dá acesso | Concedendo acesso (por usuário ou grupo) | Concedendo acesso (por usuário ou grupo), ou um grant curinga que libera de uma vez todas as mesas de dados, atuais e futuras |
| Como se restringe | Não concedendo (ou removendo o acesso) | Não concedendo (ou removendo o acesso) |
O acesso a uma Mesa de Dados se dá na aba Acesso aos Dados do usuário ou do grupo, do mesmo jeito que numa Mesa de Aplicação: concedendo aquela mesa a ele. Quem administra o Data Warehouse inteiro costuma receber o grant curinga em vez de mesa por mesa.
IMPORTANT
Ter acesso à Mesa de Dados não é pré-requisito para ver o Dashboard. Consumir dado publicado (Dashboard, exportação, Writeback) passa pelo grant de Datamart e pela Mesa de Aplicação, não pela Mesa de Dados. A Mesa de Dados governa só o lado de quem constrói: abrir a tabela no HorusDW, editar o Dataflow no HorusETL, restaurar da Lixeira.
🚪 Quem passa por cima (bypass)
O Admin do Tenant faz bypass do allow-list nas duas naturezas de mesa:
| Regra | Mesa de Aplicação (allow-list) | Mesa de Dados (allow-list) |
|---|---|---|
| Usuário comum | Vê só as mesas às quais recebeu acesso | Vê só as mesas às quais recebeu acesso (ou todas, com o grant curinga) |
| Admin do Tenant | Vê todas (bypass do allow-list) | Vê todas (bypass do allow-list) |
Em outras palavras:
- Mesa de Aplicação — o Admin do Tenant ignora o allow-list e enxerga todas as Aplicações. O único freio é o bloqueio explícito de uma Aplicação específica (a Aplicação Bloqueada, que também é honrada por ele).
- Mesa de Dados — o Admin do Tenant também ignora o allow-list e enxerga todas as mesas, sem precisar de grant algum. Não existe hoje, do lado de dados, um bloqueio por item equivalente à Aplicação Bloqueada; o controle fino de uma tabela específica é o grant de Datamart, na aba de Gerenciamento da tabela.
NOTE
Até 02/09 (antes da DEVCOMP-1, v1.1.388), a Mesa de Dados funcionava ao contrário do que a tabela acima descreve: nascia aberta, e só fechava com um bloqueio explícito que valia até para o Admin do Tenant. O modelo mudou; hoje o Admin do Tenant bypassa as duas naturezas de mesa.
📤 Publicar é uma permissão, não um privilégio de admin
Publicar um app ou uma tabela em uma mesa é uma permissão concedível — a função Publicar, na matriz de Funções do Sistema. Ela não é exclusiva de administrador.
- Quem pode publicar — qualquer usuário ou grupo que tenha a permissão Publicar no módulo correspondente (Aplicações, Tabelas, Mesas Publicadas)
- Onde pode publicar — apenas nas mesas às quais tem acesso. A permissão de Publicar libera o verbo; o acesso à mesa define o destino. Você não publica em uma mesa que não enxerga.
Ou seja: um analista sem qualquer papel administrativo pode receber a permissão de Publicar e passar a publicar suas entregas, sempre restrito às mesas dentro do seu escopo de acesso.
🗑️ A Lixeira respeita as mesmas permissões
A Lixeira (Arquivo) não é uma lista global. Ela é escopada por mesa: você só vê, restaura ou baixa o backup de itens — Aplicações, Tabelas e Fluxos — que pertencem a mesas às quais você tem acesso.
- Item de Mesa de Aplicação — segue o allow-list: só aparece na sua Lixeira se você tem acesso àquela Mesa de Aplicação (ou é Admin do Tenant, que enxerga todas)
- Item de Mesa de Dados — segue o allow-list também: só aparece na sua Lixeira se você tem acesso àquela Mesa de Dados (ou é Admin do Tenant, que enxerga todas)
Isso significa que a Lixeira nunca é uma porta dos fundos: um usuário sem acesso a uma Mesa de Dados não recupera nem baixa o backup de uma tabela daquela mesa pela Lixeira.
Detalhes de retenção, restore e backup local estão em Arquivo (visão geral).
🔒 Writeback e Cadastros seguem o grant de tabela, não a mesa
O consumo de dados via Writeback / Cadastros é eixo de DataViz, e quem decide é só o grant de Datamart sobre aquela tabela (que define se você lê, cria, edita, importa ou exporta as linhas), além de owner, Admin e Seer. A Mesa de Dados da tabela não entra nessa conta.
NOTE
Até 02/09 (antes da DEVCOMP-1) existia uma camada a mais: o bloqueio de Mesa de Dados prevalecia sobre o grant de Datamart, e um usuário bloqueado na mesa não lia nem exportava as linhas mesmo com grant. Essa camada saiu. Hoje ter, ou não ter, acesso à Mesa de Dados de uma tabela não muda o que o Writeback libera.
Ou seja, para um usuário ler, criar, editar ou exportar via Writeback, o que importa é ter o grant de Datamart sobre aquela tabela específica (ou ser owner, Admin ou Seer). A Mesa de Dados onde a tabela mora é irrelevante para essa decisão.
🔑 Resumo
- Mesa de Aplicação e Mesa de Dados = allow-list, nascem trancadas. Ninguém vê até receber acesso explícito, por usuário ou grupo. O Admin do Tenant faz bypass das duas.
- Mesa de Dados trava a construção, HorusDW, HorusETL e a Lixeira desses recursos, não o consumo: não esconde o Dashboard de quem tem acesso à Mesa de Aplicação, nem o Writeback de quem tem o grant de Datamart da tabela.
- Aplicação Bloqueada é hoje o único bloqueio, do lado de aplicação, que sobrevive ao bypass de admin.
- Publicar é permissão concedível, restrita às mesas às quais você tem acesso, não é exclusiva de admin.
- Lixeira segue o allow-list de cada natureza de mesa; Writeback segue só o grant de Datamart da tabela.
Veja também: