v2026.6.12
Data de lançamento: 30 de junho de 2026
✨ Novas Funcionalidades
Permissões granulares por usuário
Cada membro da organização pode ter um conjunto de permissões exclusivo, configurado individualmente — independente do role ou grupo atribuído.
A hierarquia de resolução é exclusiva (sem mesclagem entre camadas):
- Permissões customizadas do usuário — se existirem, têm prioridade total
- Grupo de permissão atribuído — usado quando não há permissões customizadas
- Template do role — fallback final
Regra de ouro: o role
ownersempre usa o template completo e nunca pode ser restringido por permissões customizadas ou grupos.
Para que serve?
- Liberar ou restringir módulos específicos para um usuário sem alterar o role dele
- Definir se um atendente vê todos os clientes/funis ou apenas os que atende
- Criar combinações de acesso não cobertas pelos roles padrão
Como configurar?
- Acesse Configurações → Membros
- Encontre o membro desejado e clique em Permissões
- Na aba Permissão individual, ative os módulos e ações desejadas
- Marque ou desmarque flags especiais como "Ver todos os clientes" ou "Ver todas as conversas"
- Salve — as permissões entram em vigor imediatamente
Controle de visibilidade de clientes e CRM
A flag canAccessAll nos módulos Clientes e CRM determina o escopo de visão do usuário:
| Flag | Comportamento no sidebar | Comportamento nos filtros |
|---|---|---|
canAccessAll: true | Exibe "Os que atendo" e "Todos" | Acesso livre |
canAccessAll: false | Exibe somente "Os que atendo" | Filtrado automaticamente pelo próprio ID |
Roles com visão total por padrão: owner, admin, manager, financial.
Roles com visão restrita por padrão: agent, agent_limited, sales, medical_doctor, medical_assistant.
Navegação direta ao submenu único
Quando um item de menu possui submenus mas apenas um deles está disponível para o usuário (por conta de permissões), o clique navega diretamente para aquela página — sem abrir o painel expansível.
Antes: clicar em "Clientes" expandia o menu, mesmo com um único submenu.
Agora: clicar em "Clientes" vai direto para a única opção disponível.
🔄 Alterações
Verificações de role substituídas por permissões efetivas
Todos os pontos do frontend e do backend que comparavam role === 'admin' || role === 'owner' diretamente foram migrados para usar as permissões efetivas:
- Frontend:
isOwnerOrAdmin,isOwnere flags específicas de módulo (customersPermissions.canAccessAll,chatsPermissions.canAssignToOthers) — derivados do hookusePermissions - Backend:
req.isAdmin,req.isOwnerereq.is_superadmin— populados no middleware de autenticação sem queries adicionais ao banco
Flags de acesso no middleware de autenticação
O middleware applyMembershipAuthContextToRequest agora define req.isOwner e req.isAdmin com base no role do membro, direto na camada de autenticação. Controllers e handlers deixam de fazer queries redundantes ao banco para verificar o role do usuário que fez a requisição.
Proteção de rotas por módulo (backend)
Middleware requireModuleAccess aplicado às rotas de: configurações, integrações, billing, Stripe, subscription, grupos de permissão, equipes de atendimento e UTM.
Proteção de rotas por módulo (frontend)
Componente ModuleGuard envolvendo grupos de rotas do React Router para: financeiro, relatórios, membros, grupos de permissão, equipes, mensagens em massa, fluxos, prompts, billing, canais, médico, documentos, PDV, UTM e configurações.
🐛 Correções
Permissões customizadas ignoravam canAccessAll: false
Quando um usuário tinha permissões customizadas definidas mas o campo canAccessAll no módulo de clientes não estava marcado, o sistema usava o valor padrão true — exibindo todos os clientes indevidamente. Corrigido: a ausência da flag em permissões customizadas agora é tratada como false (restritivo por padrão).
🎯 Benefícios
- ✅ Controle de acesso por módulo sem necessidade de criar roles específicos
- ✅ Owner nunca perde acesso total, mesmo com permissões customizadas configuradas
- ✅ Sidebar e filtros adaptam-se automaticamente ao escopo de visão do usuário
- ✅ Navegação mais fluida: sem expansão desnecessária de menus com item único
- ✅ Backend sem queries extras: verificações de acesso resolvidas na camada de autenticação