📊 Relatório Minucioso: Sistema de Permissões e Equipes ArboreoLab
Data: 08 de Janeiro de 2026
Responsável: Engenheiro de Software Sênior
Foco: Usuários Convidados para Projetos
Versão: 1.0.0
Índice
- Resumo Executivo
- Arquitetura de Databases
- Estrutura de Tabelas ArboreolabADM
- Sistema de Permissões RBAC
- Fluxo de Convite de Usuários
- O Que o Usuário Convidado Pode Ver
- Comparativo com a Indústria
- Recomendações e Melhorias
Resumo Executivo
O ArboreoLab implementa um sistema Multi-Tenant com RBAC Contextual (Role-Based Access Control), onde:
| Aspecto | Estado Atual |
|---|---|
| Isolamento de Dados | ✅ Por Database ([Projeto]Vector) |
| Autenticação | ✅ JWT + Google OAuth |
| Autorização | ✅ RBAC com 5 níveis hierárquicos |
| Convites de Equipe | ✅ Implementado (gestor+ pode convidar) |
| Limites por Plano | ✅ Controlado por assinaturas |
| Auditoria | ✅ Logs de projeto (arb_projeto_logs) |
Databases Identificados
┌──────────────────────────────────────────────────────┐
│ Servidor MariaDB 11.8 │
├──────────────────────────────────────────────────────┤
│ ArboreolabADM │ Governança centralizada │
│ ClioVector │ Tenant: Template/Clio │
│ GeopoliticasVector │ Tenant: Geopolíticas │
│ arboreolabconn │ Conexões (legado?) │
└──────────────────────────────────────────────────────┘
Arquitetura de Databases
Separação Multi-Tenant
O ArboreoLab utiliza isolamento completo por database:
┌───────────────────────────────────────────────────────────────┐
│ ArboreolabADM (Governança) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ arb_usuarios │ Todos os usuários do sistema │ │
│ │ arb_projetos │ Registro de todos os projetos │ │
│ │ arb_projeto_usuarios │ Relação N:N (equipes/convites) │ │
│ │ arb_assinaturas │ Limites por plano │ │
│ │ arb_projeto_logs │ Auditoria de ações │ │
│ │ arb_config │ Configurações globais │ │
│ └─────────────────────────────────────────────────────────┘ │
└───────────────────────────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ ClioVector │ │GeopoliticasVector │ │ [Novo]Vector │
├───────────────────┤ ├───────────────────┤ ├───────────────────┤
│ clio_ocr │ │ clio_ocr │ │ clio_ocr │
│ clio_ocr_segments │ │ clio_ocr_segments │ │ clio_ocr_segments │
│ clio_entidades │ │ clio_entidades │ │ clio_entidades │
│ clio_documentos │ │ clio_documentos │ │ clio_documentos │
│ embeddings_768 │ │ embeddings_768 │ │ embeddings_768 │
└───────────────────┘ └───────────────────┘ └───────────────────┘
Benefício de Segurança: Um usuário convidado para o projeto "Geopoliticas" NUNCA terá acesso aos dados de "Clio" ou outros projetos.
Estrutura de Tabelas ArboreolabADM
1. arb_usuarios - Cadastro Global de Usuários
| Campo | Tipo | Descrição |
|---|---|---|
id | INT PK | Identificador único |
email | VARCHAR(255) UNIQUE | Email (login) |
nome | VARCHAR(255) | Nome completo |
organizacao | VARCHAR(255) | Organização/empresa |
google_id | VARCHAR(100) | ID do Google OAuth |
auth_provider | ENUM | google, email, sso |
status | ENUM | pendente, ativo, suspenso, inativo |
role | ENUM | admin, gestor, usuario, visitante (global) |
plano_selecionado | ENUM | gratuito, basico, profissional, enterprise |
Dados Atuais:
| id | email | status | role | plano |
|----|--------------------------------|----------|---------|-------------|
| 3 | adm.geopoliticas@gmail.com | ativo | admin | gratuito |
| 25 | romao.doug@gmail.com | ativo | usuario | gratuito |
| 28 | recruta@gmail.com | ativo | usuario | gratuito |
| 29 | teste.convite.novo@exemplo.com | pendente | usuario | gratuito |
2. arb_projetos - Registro de Projetos
| Campo | Tipo | Descrição |
|---|---|---|
id | INT PK | Identificador único |
usuario_id | INT FK | Proprietário (owner) do projeto |
nome | VARCHAR(255) | Nome do projeto |
slug | VARCHAR(100) | Identificador URL-friendly |
database_name | VARCHAR(100) UNIQUE | Nome do database ([Nome]Vector) |
storage_type | ENUM | local, google_drive, onedrive, icloud, s3 |
status | ENUM | configurando, ativo, pausado, arquivado |
instalacao_completa | TINYINT | 0/1 - Wizard concluído |
Dados Atuais:
| id | usuario_id | nome | database_name | status |
|----|------------|-----------------------------|--------------------|--------|
| 4 | 3 | Geopoliticas Institucionais | GeopoliticasVector | ativo |
⚠️ Observação: O campo
usuario_iddefine o OWNER do projeto (nível 100).
3. arb_projeto_usuarios - Equipe do Projeto (CRÍTICA)
Esta é a tabela central de permissões para usuários convidados:
| Campo | Tipo | Descrição |
|---|---|---|
id | INT PK | Identificador único |
projeto_id | INT FK | Projeto ao qual pertence |
usuario_id | INT FK | Usuário membro |
role | ENUM | admin, gestor, usuario, visitante |
permissao_leitura | TINYINT | 1 = pode visualizar |
permissao_escrita | TINYINT | 1 = pode editar/upload |
permissao_exclusao | TINYINT | 1 = pode deletar |
permissao_admin | TINYINT | 1 = acesso administrativo |
status | ENUM | pendente, ativo, suspenso, removido |
convidado_por | INT FK | Quem enviou o convite |
convite_aceito_em | TIMESTAMP | Data de aceite |
Dados Atuais:
| usuario | projeto | role | leitura | escrita | exclusão | status | convidado_por |
|-------------|--------------|---------|---------|---------|----------|----------|---------------|
| user 3 | Geopoliticas | admin | ✓ | ✓ | ✓ | ativo | NULL (owner) |
| user 25 | Geopoliticas | usuario | ✓ | ✗ | ✗ | removido | 3 |
| user 28 | Geopoliticas | usuario | ✓ | ✗ | ✗ | ativo | 3 |
| user 29 | Geopoliticas | usuario | ✓ | ✗ | ✗ | removido | 3 |
4. arb_assinaturas - Limites por Plano
| Campo | Tipo | Descrição |
|---|---|---|
projeto_id | INT FK | Projeto associado |
plano | ENUM | gratuito, basico, profissional, enterprise |
status | ENUM | ativo, expirado, cancelado, trial |
limite_documentos | INT | Máximo de documentos |
limite_storage_gb | DECIMAL | Limite de armazenamento |
limite_ocr_mensal | INT | OCR por mês |
limite_usuarios | INT | Máximo de membros na equipe |
Dados Atuais:
| projeto_id | plano | status | limite_docs | limite_storage | limite_usuarios |
|------------|------------|--------|-------------|----------------|-----------------|
| 4 | enterprise | ativo | 10.000 | 50 GB | 5 |
5. arb_projeto_logs - Auditoria
| Campo | Tipo | Descrição |
|---|---|---|
projeto_id | INT FK | Projeto |
usuario_id | INT FK | Quem executou a ação |
acao | ENUM | Tipo de ação (30+ tipos) |
descricao | TEXT | Descrição legível |
dados_anteriores | JSON | Snapshot antes |
dados_novos | JSON | Snapshot depois |
ip_origem | VARCHAR(45) | IP do usuário |
nivel | ENUM | debug, info, warning, error, critical |
Ações Relevantes para Equipes:
config_alterada- Quando membro é adicionado/alterado/removidousuario_login,usuario_logout- Sessões
6. arb_projeto_credentials - Credenciais por Projeto
Armazena tokens OAuth, API keys, etc. de forma criptografada:
| Campo | Tipo | Descrição |
|---|---|---|
projeto_id | INT FK | Projeto dono |
credential_type | ENUM | google_oauth_token, gemini_api_key, etc. |
credential_value_encrypted | TEXT | Valor criptografado (AES-256) |
is_active | TINYINT | Se está ativa |
🔒 Segurança: Credenciais são isoladas por projeto - um usuário convidado para Projeto A não tem acesso às credenciais do Projeto B.
Sistema de Permissões RBAC
Hierarquia de Roles
┌─────────────────────────────────────────────────────────────────────┐
│ HIERARQUIA DE PERMISSÕES │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ OWNER (100) ─────────────────────────────────────────────────────► │
│ │ ✓ Deletar projeto │
│ │ ✓ Gerenciar credenciais (OAuth, API Keys) │
│ │ ✓ Finalizar instalação │
│ │ ✓ Tudo abaixo │
│ │ │
│ ADMIN (90) ──────────────────────────────────────────────────────► │
│ │ ✓ Editar configurações do projeto │
│ │ ✓ Remover membros da equipe │
│ │ ✓ Alterar roles de membros │
│ │ ✓ Configurar storage │
│ │ ✓ Tudo abaixo │
│ │ │
│ GESTOR (50) ─────────────────────────────────────────────────────► │
│ │ ✓ Convidar membros │
│ │ ✓ Deletar documentos │
│ │ ✓ Sincronizar Tainacan │
│ │ ✓ Tudo abaixo │
│ │ │
│ USUÁRIO (10) ────────────────────────────────────────────────────► │
│ │ ✓ Upload de arquivos │
│ │ ✓ Editar documentos/metadados │
│ │ ✓ Executar OCR │
│ │ ✓ Tudo abaixo │
│ │ │
│ VISITANTE (0) ───────────────────────────────────────────────────► │
│ ✓ Apenas visualização (GET requests) │
│ ✓ Buscar documentos │
│ ✓ Ver entidades │
│ │
└─────────────────────────────────────────────────────────────────────┘
Implementação Backend
Middleware Chain (ordem obrigatória):
verifyJwt → selectDatabase → requireRole(minRole)
Arquivo: node/backend/middleware/verifyPermissions.js
// Níveis definidos
const ROLES = {
owner: { level: 100 },
admin: { level: 90 },
gestor: { level: 50 },
usuario: { level: 10 },
visitante: { level: 0 }
};
// Middleware factory
function requireRole(minRole) {
return async (req, res, next) => {
const userLevel = getRoleLevel(req.projectInfo?.role);
const requiredLevel = getRoleLevel(minRole);
if (userLevel >= requiredLevel) {
req.userPermissions = {
role: userRole,
isOwner: userRole === 'owner',
isAdmin: userLevel >= 90,
canManage: userLevel >= 50,
canWrite: userLevel >= 10
};
return next();
}
return res.status(403).json({ error: 'Acesso Negado' });
};
}
Implementação Frontend
Arquivo: iface-frontend-vuejs/src/composables/usePermissions.ts
// Uso no componente
const { canAdmin, canWrite, isOwner } = usePermissions()
// No template
<button v-if="canAdmin" @click="removerMembro">Remover</button>
Fluxo de Convite de Usuários
Diagrama de Sequência
┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ Admin/Gestor │ │ Backend │ │ Database │ │ Novo Membro │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │ │
│ POST /projeto/:id/equipe │ │
│ { email, role } │ │ │
│───────────────────►│ │ │
│ │ │ │
│ │ Verifica permissão │ │
│ │ (gestor+ pode) │ │
│ │ │ │
│ │ Verifica plano │ │
│ │ (tem limite?) │ │
│ │───────────────────►│ │
│ │ │ │
│ │ Usuário existe? │ │
│ │◄───────────────────│ │
│ │ │ │
│ │ Se não: cria com │ │
│ │ status='pendente' │ │
│ │───────────────────►│ │
│ │ │ │
│ │ INSERT │ │
│ │ arb_projeto_usuarios│ │
│ │ status='pendente' │ │
│ │───────────────────►│ │
│ │ │ │
│ 200 OK (membro │ │ │
│ adicionado) │ │ │
│◄───────────────────│ │ │
│ │ │ │
│ │ │ │
│ │ │ Faz login │
│ │ │◄───────────────────│
│ │ │ │
│ │ GET /convites/pendentes │
│ │◄────────────────────────────────────────│
│ │ │ │
│ │ Lista convites │ │
│ │────────────────────────────────────────►│
│ │ │ │
│ │ POST /convites/:id/aceitar │
│ │◄────────────────────────────────────────│
│ │ │ │
│ │ UPDATE status= │ │
│ │ 'ativo' │ │
│ │───────────────────►│ │
│ │ │ │
│ │ Acesso liberado │ │
│ │────────────────────────────────────────►│
Endpoints Relevantes
| Método | Endpoint | Descrição | Mínimo |
|---|---|---|---|
| POST | /api/projeto/:id/equipe | Convidar membro | gestor |
| GET | /api/projeto/:id/equipe | Listar equipe | visitante |
| PUT | /api/projeto/:id/equipe/:usuarioId | Alterar role | admin |
| DELETE | /api/projeto/:id/equipe/:usuarioId | Remover membro | admin |
| GET | /api/projeto/convites/pendentes | Listar convites | usuário |
| POST | /api/projeto/convites/:id/aceitar | Aceitar convite | usuário |
O Que o Usuário Convidado Pode Ver
Por Role
| Recurso | Owner | Admin | Gestor | Usuário | Visitante |
|---|---|---|---|---|---|
| Documentos | |||||
| Visualizar lista | ✓ | ✓ | ✓ | ✓ | ✓ |
| Ver conteúdo OCR | ✓ | ✓ | ✓ | ✓ | ✓ |
| Ver entidades | ✓ | ✓ | ✓ | ✓ | ✓ |
| Busca semântica | ✓ | ✓ | ✓ | ✓ | ✓ |
| Upload novos | ✓ | ✓ | ✓ | ✓ | ✗ |
| Editar metadados | ✓ | ✓ | ✓ | ✓ | ✗ |
| Deletar | ✓ | ✓ | ✓ | ✗ | ✗ |
| Equipe | |||||
| Ver membros | ✓ | ✓ | ✓ | ✓ | ✓ |
| Convidar | ✓ | ✓ | ✓ | ✗ | ✗ |
| Remover | ✓ | ✓ | ✗ | ✗ | ✗ |
| Alterar roles | ✓ | ✓ | ✗ | ✗ | ✗ |
| Projeto | |||||
| Ver configurações | ✓ | ✓ | ✓ | ✓ | ✓ |
| Editar configurações | ✓ | ✓ | ✗ | ✗ | ✗ |
| Conectar storage | ✓ | ✓ | ✗ | ✗ | ✗ |
| Deletar projeto | ✓ | ✗ | ✗ | ✗ | ✗ |
| Credenciais | |||||
| Ver API Keys | ✓ | ✗ | ✗ | ✗ | ✗ |
| Gerenciar OAuth | ✓ | ✗ | ✗ | ✗ | ✗ |
Isolamento Entre Projetos
Um usuário convidado para Projeto A:
- ✅ Vê apenas dados do Projeto A
- ✅ Acessa apenas o database
ProjetoAVector - ❌ NUNCA acessa dados do Projeto B
- ❌ NUNCA vê credenciais de outros projetos
- ❌ NUNCA lista projetos dos quais não é membro
Comparativo com a Indústria
Modelo ArboreoLab vs Padrões de Mercado
1. Modelo SaaS Clássico (Slack, Notion, Figma)
┌─────────────────────────────────────────────────────────────────────┐
│ MODELO TÍPICO SAAS │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ ORGANIZAÇÃO │ ← Conta do assinante (billing) │
│ │ (Workspace) │ │
│ └────────┬────────┘ │
│ │ │
│ ├──── Owner/Admin (quem paga) │
│ │ │
│ └──── Membros com roles: │
│ • Admin (tudo) │
│ • Member (padrão) │
│ • Guest/Viewer (limitado) │
│ │
│ Recursos compartilhados: │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Projeto │ │ Projeto │ │ Projeto │ ← Todos acessam │
│ │ A │ │ B │ │ C │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ Problema: Todos veem tudo (ou precisam de granularidade extra) │
└─────────────────────────────────────────────────────────────────────┘
2. Modelo ArboreoLab (Isolamento por Projeto)
┌─────────────────────────────────────────────────────────────────────┐
│ MODELO ARBOREOLAB │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ PROJETO A │ │ PROJETO B │ ← Databases separados │
│ │ (Database A) │ │ (Database B) │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ ├── Owner (paga A) ├── Owner (paga B) │
│ │ │ │
│ └── Equipe A └── Equipe B │
│ • Admin • Gestor │
│ • Gestor • Usuário │
│ • Usuário │
│ │
│ ✅ Isolamento TOTAL entre projetos │
│ ✅ Cada projeto = tenant independente │
│ ✅ Um usuário pode estar em múltiplos projetos com roles │
│ diferentes em cada um │
│ │
└─────────────────────────────────────────────────────────────────────┘
Comparação com Referências de Mercado
| Aspecto | Slack | Notion | Figma | GitHub | ArboreoLab |
|---|---|---|---|---|---|
| Unidade de billing | Workspace | Workspace | Org | Org/User | Projeto |
| Isolamento | Canais | Páginas | Projetos | Repos | Database |
| RBAC | 4 níveis | 4 níveis | 3 níveis | 5 níveis | 5 níveis |
| Convites | Username | ||||
| Multi-tenant | Shared DB | Shared DB | Shared DB | Shared DB | Isolado |
| Limites | Por plano | Por plano | Por plano | Por plano | Por plano |
Vantagens do Modelo ArboreoLab
-
Segurança por Design
- Dados de um cliente NUNCA tocam o database de outro
- Vazamento de dados entre tenants é estruturalmente impossível
-
Compliance Facilitado
- LGPD/GDPR: Exclusão de dados por tenant é
DROP DATABASE - Auditoria isolada por projeto
- LGPD/GDPR: Exclusão de dados por tenant é
-
Escalabilidade
- Cada projeto pode ser migrado independentemente
- Backup/restore granular por tenant
-
Flexibilidade de Roles
- Mesmo usuário pode ser Owner em Projeto A e Visitante em Projeto B
- Roles contextuais por projeto
Desvantagens e Riscos
-
Complexidade Operacional
- Mais databases para gerenciar
- Migrations precisam rodar em todos os tenants
-
Overhead de Conexões
- Cada tenant precisa de seu próprio pool
- Limite de
max_connectionsdo MariaDB
-
Onboarding do Usuário
- Usuário precisa entender o conceito de "projetos"
- Troca de contexto entre projetos
Recomendações e Melhorias
Curto Prazo (1-2 semanas)
| Prioridade | Melhoria | Justificativa |
|---|---|---|
| 🔴 Alta | Implementar notificação de convite (email) | Usuário não sabe que foi convidado |
| 🔴 Alta | Adicionar role admin na tabela arb_projeto_usuarios | Atualmente só owner tem admin_flag |
| 🟡 Média | Dashboard de convites pendentes no login | UX para novos usuários |
| 🟡 Média | Expiração de convites (30 dias) | Segurança |
Médio Prazo (1-2 meses)
| Prioridade | Melhoria | Justificativa |
|---|---|---|
| 🟡 Média | Permissões granulares por recurso | Ex: acesso só a determinadas pastas |
| 🟡 Média | Grupos de permissão | "Equipe OCR", "Equipe Metadados" |
| 🟢 Baixa | SSO corporativo (SAML/OIDC) | Clientes enterprise |
Longo Prazo (3-6 meses)
| Prioridade | Melhoria | Justificativa |
|---|---|---|
| 🟢 Baixa | Permissões por pasta/coleção | Acervo X só para Equipe Y |
| 🟢 Baixa | Hierarquia de organizações | Holding → Empresas → Projetos |
| 🟢 Baixa | API de gerenciamento de equipes | Automação de provisionamento |
📊 Métricas de Segurança
Checklist de Auditoria
✅ Senhas: Nunca armazenadas em texto claro
✅ Tokens: Criptografados com AES-256-GCM
✅ JWT: Expira em 24h
✅ Sessions: Invalidadas no logout
✅ Logs: Todas as ações sensíveis são logadas
✅ HTTPS: Forçado em produção
✅ Isolamento: Databases separados por tenant
✅ RBAC: 5 níveis hierárquicos
✅ Convites: Verificação de limite por plano
Testes de Intrusão Recomendados
-
IDOR (Insecure Direct Object Reference)
- Tentar acessar projeto_id de outro tenant
- Tentar acessar usuário_id de outro projeto
-
Privilege Escalation
- Usuário tentando alterar própria role
- Visitante tentando fazer POST
-
Token Manipulation
- JWT modificado
- Token expirado
📝 Conclusão
O sistema de permissões do ArboreoLab está bem estruturado para o modelo multi-tenant com equipes:
| Aspecto | Status | Nota |
|---|---|---|
| Arquitetura RBAC | ✅ Implementado | 5 níveis hierárquicos |
| Isolamento de dados | ✅ Robusto | Por database |
| Fluxo de convites | ✅ Funcional | Com notificação por email |
| Limites por plano | ✅ Implementado | Assinaturas controlam |
| Auditoria | ✅ Completa | 30+ tipos de ação |
O que o usuário convidado pode ver:
- Documentos do projeto ao qual foi convidado
- Entidades e OCR do projeto
- Membros da equipe do projeto
- Configurações (se role permitir)
O que o usuário convidado NÃO pode ver:
- Qualquer dado de outros projetos
- Credenciais do projeto (exceto owner)
- Usuários de outros projetos
- Logs de outros projetos
🔄 Atualizações
09/01/2026 - Sistema de Notificação por Email
- ✅ Postfix + OpenDKIM + TLS configurados e operacionais
- ✅ SPF, DKIM, DMARC passando verificação Gmail
- ✅ Página de aceite de convite implementada no frontend
- ✅ Fluxo completo testado - convite enviado, aceito, usuário com acesso
- ✅ Permissões aplicadas corretamente conforme role definido
09/01/2026 - Sistema de Permissões Dinâmicas (RBAC Configurável)
- ✅ Tabela
arb_projeto_permissoes- Permite ao owner definir roles mínimas por recurso - ✅ Endpoint
/api/permissoes- CRUD completo para gerenciamento - ✅ Store
permissoesStore- Cache de permissões no frontend - ✅ Router Guard atualizado - Verifica permissões antes de permitir navegação
- ✅ Interface de gerenciamento -
/projeto/permissoespara o owner configurar
09/01/2026 - Correção: Role aparecendo como visitante para o Owner
- ✅ Causa raiz: o GET
/api/permissoesretornavaminha_role = visitantequandoreq.userPermissionsnão era preenchido (faltava middleware de role nessa rota). - ✅ Correção: adicionada validação mínima de leitura no endpoint (
verifyJwt → selectDatabase → requireRead), garantindo injeção dereq.userPermissionse retorno correto deminha_role/meu_nivel. - ✅ Hardening do JWT: normalização do payload para preencher
emaila partir deuserId/idquando esses campos contiverem um email (evita logs “anônimo” e falhas de cálculo de role). - ✅ Efeito prático: owner volta a ser identificado como
owner (100)e o router guard deixa de bloquear telas como/armazenamentoindevidamente.
Arquitetura de Permissões Dinâmicas
┌─────────────────────────────────────────────────────────────────┐
│ CAMADA DE CONFIGURAÇÃO │
│ (Owner configura via /projeto/permissoes) │
├─────────────────────────────────────────────────────────────────┤
│ arb_projeto_permissoes (por projeto/tenant) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ projeto_id │ recurso │ role_minima │ visivel │ edit │ │
│ │ 4 │ /busca │ usuario │ true │ true │ │
│ │ 4 │ /armazenamento │ gestor │ true │ false│ │
│ │ 4 │ /entidades │ admin │ true │ true │ │
│ └────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ CAMADA DE APLICAÇÃO │
├─────────────────────────────────────────────────────────────────┤
│ Backend: Middleware verifica permissão por recurso │
│ Frontend: Router guard + permissoesStore │
└─────────────────────────────────────────────────────────────────┘
Recursos Configuráveis (17 views)
| Grupo | Recursos | Role Padrão |
|---|---|---|
| Dashboard | /inicio, /estatisticas | visitante, usuario |
| Busca | /busca-documentos, /view-docs-rel, /entidades-rel-d3 | visitante, visitante, usuario |
| Documentos | /gerenciadores, /gerenciador-dados, etc. | gestor |
| Armazenamento | /armazenamento, /propriedades | gestor, usuario |
| IA | /ai | gestor |
| Projeto | /projeto, /projeto/wizard, /projeto/permissoes | admin, owner, owner |
| Perfil | /perfil | visitante |
🔜 Próxima Fase: Controle de Conteúdo por Roles
- Controle de campos por roles - Definir quais campos são visíveis/editáveis por role
- Componentes condicionais - v-if baseado em permissões granulares
🔜 Melhorias de Interface (Backlog)
- Botão "Reenviar convite" para convites expirados
- Opção de cancelar convite pendente
- Lista de convites pendentes na interface
Relatório criado em 08/01/2026
Atualizado em 09/01/2026
Engenheiro de Software Sênior - ArboreoLab