Pular para o conteúdo principal

Controle de Acesso Baseado em Regras

Funções, Permissões e Usuários no OmniCRM​

OmniCRM utiliza controle de acesso baseado em funções (RBAC): pessoas (Usuários) são atribuídas a uma ou mais Funções, e cada Função é um conjunto de Permissões. As Permissões são a menor unidade de acesso (por exemplo, view_customer, create_inventory). O acesso efetivo de um usuário é a união das permissões de todas as funções atribuídas.

Propósito​

RBAC permite:

  1. Proteção de Dados --- Usuários só veem e fazem o que estão autorizados a fazer.
  2. Adequação Operacional --- Funções refletem funções de trabalho (Admin, Suporte, Finanças, Administrador de Cliente).
  3. Administração Simples --- Conceda acesso atribuindo funções; evite a microgestão por usuário.
  4. Isolamento de Inquilinos --- Permissões de "ver próprio ..." limitam a visibilidade aos dados de cliente/inquilino do próprio usuário.

RBAC Permissions

Como Usuários, Funções e Permissões se Encaixam​

  • Usuários --- Pessoas reais que fazem login no OmniCRM.
  • Permissões --- Capacidades atômicas (por exemplo, view_customer, delete_product).
  • Funções --- Conjuntos nomeados de permissões (por exemplo, Admin, Suporte, Finanças).
  • Atribuição --- Usuários recebem uma ou mais funções; as permissões se agregam.

RBAC Permissions

A autenticação prova quem você é (JWT, chave da API ou IP na lista branca). A autorização (funções/permissões) decide o que você pode fazer.

Gerenciando Usuários​

O sistema de gerenciamento de usuários do OmniCRM permite que administradores criem e gerenciem usuários da equipe (administradores, agentes de atendimento ao cliente), visualizem e modifiquem funções de usuários, redefinam senhas, gerenciem autenticação de dois fatores e controlem o acesso dos usuários.

Tipos de Usuários​

Usuários Clientes - Criados via autoinscrição ou por administradores. Atribuídos automaticamente à função "Cliente". Esses usuários acessam o portal de autoatendimento para gerenciar seus serviços, visualizar uso, pagar faturas, etc.

Usuários da Equipe - Criados por administradores com permissões apropriadas. Podem ser atribuídos a funções como Admin, Suporte, Finanças, etc. Esses usuários acessam a interface do CRM para gerenciar clientes, provisionar serviços, lidar com faturamento, etc.

Usuários Administrativos - Usuários com a permissão admin. Têm acesso total ao sistema, incluindo gerenciamento de usuários, gerenciamento de funções e todos os endpoints protegidos.

O usuário administrativo inicial é criado pela equipe do Omnitouch quando o sistema é implantado.

Adicionando Novos Usuários (Administradores e CSAs)​

Administradores podem criar novos usuários da equipe através da interface da Web ou da API.

Via Interface da Web​

  1. Navegue até Usuários e Funções - Acesse a interface de gerenciamento de usuários a partir do menu de administração
  2. Clique em "Adicionar Usuário" - Abre o formulário de criação de usuário

Adding a User

  1. Preencha os Detalhes do Usuário:
    • Nome de Usuário - Nome de usuário único para login (obrigatório)
    • Email - Endereço de email do usuário (obrigatório, deve ser único)
    • Senha - Senha temporária (obrigatório, o usuário deve alterá-la no primeiro login)
    • Primeiro Nome - Primeiro nome do usuário (obrigatório)
    • Nome do Meio - Nome do meio do usuário (opcional)
    • Último Nome - Último nome do usuário (obrigatório)
    • Número de Telefone - Número de telefone de contato (opcional)
    • Função - Selecione uma ou mais funções para atribuir (obrigatório)
    • Contato do Cliente - Opcionalmente vincule o usuário a um registro de contato do cliente (para usuários clientes)
  2. Clique em "Criar Usuário" - O usuário é criado e pode imediatamente fazer login com as credenciais fornecidas
  3. Usuário recebe notificação - Opcionalmente envie um email de boas-vindas com instruções de login

Melhores Práticas:

  • Use uma senha temporária como TempP@ssw0rd! e exija que o usuário a altere no primeiro login
  • Atribua funções apropriadas com base na função de trabalho (veja os Designs Típicos de Função abaixo)
  • Ative a 2FA para todo o pessoal administrativo e de suporte
  • Vincule usuários clientes ao seu registro de contato do cliente para escopo de dados adequado

Via API​

Crie um usuário programaticamente:

Endpoint: POST /auth/users

Permissão Necessária: admin

Corpo da Requisição:

{
  "username": "john.smith",
  "email": "john.smith@company.com",
  "password": "TempP@ssw0rd!",
  "first_name": "John",
  "middle_name": "D",
  "last_name": "Smith",
  "phone_number": "+61412345678",
  "role": "Support"
}

Resposta:

{
  "id": 123,
  "username": "john.smith",
  "email": "john.smith@company.com",
  "first_name": "John",
  "last_name": "Smith",
  "roles": ["Support"],
  "created": "2025-01-04T10:30:00Z"
}

Atribuindo Múltiplas Funções:

Usuários podem ter múltiplas funções. As permissões são aditivas (união de todas as permissões das funções atribuídas).

Para atribuir múltiplas funções, inclua-as na requisição:

{
  "username": "jane.doe",
  "email": "jane.doe@company.com",
  "password": "TempP@ssw0rd!",
  "first_name": "Jane",
  "last_name": "Doe",
  "role": "Support,Finance"
}

Ou use o endpoint de atribuição de função após a criação do usuário:

POST /auth/roles/{role_id}/users/{user_id}

Visualizando e Pesquisando Usuários​

Listar Todos os Usuários (Admin):

GET /auth/users

Retorna uma lista paginada de todos os usuários com suas funções e informações básicas.

Pesquisar Usuários:

GET /auth/users/search?search={query}&filters={"role":["Support"]}&page=1&per_page=50

Filtrar por:

  • Nome da função
  • Domínio do email
  • Status ativo/excluído
  • Status de 2FA ativado
  • Data do último login

Obter Usuário Específico:

GET /auth/users/{user_id}

Retorna detalhes completos do usuário, incluindo:

  • Informações pessoais
  • Funções atribuídas e permissões efetivas
  • Status de 2FA
  • Último login e informações de sessão
  • Contato do cliente vinculado (se aplicável)

Criando e Gerenciando Funções​

As funções são coleções de permissões que podem ser atribuídas a usuários. Em vez de atribuir permissões individualmente a cada usuário, você cria funções que agrupam permissões relacionadas e atribui essas funções aos usuários.

Criando uma Nova Função​

Via Interface da Web:

  1. Navegue até Usuários e Funções → aba Funções
  2. Clique em "Criar Função"
  3. Insira os detalhes da função:
    • Nome - Nome curto e descritivo (por exemplo, "Tier2_Support")
    • Descrição - Explique o propósito e as responsabilidades da função
  4. Clique em "Criar"
  5. A função é criada sem permissões; adicione permissões na próxima etapa

Via API:

Endpoint: POST /auth/roles

Permissão Necessária: admin

Requisição:

{
  "name": "Tier2_Support",
  "description": "Equipe de suporte de nível 2 com acesso elevado de provisionamento"
}

Resposta:

{
  "id": 45,
  "name": "Tier2_Support",
  "description": "Equipe de suporte de nível 2 com acesso elevado de provisionamento",
  "permissions": [],
  "users": []
}

Adicionando Permissões a uma Função​

Uma vez que uma função é criada, atribua permissões para definir o que os usuários com essa função podem fazer.

Via Interface da Web:

  1. Navegue até Usuários e Funções → aba Funções
  2. Clique no nome da função para visualizar os detalhes
  3. Na seção Permissões, clique em "Adicionar Permissão"
  4. Selecione uma ou mais permissões da lista
  5. Clique em "Adicionar" - As permissões são imediatamente atribuídas

Managing Role Permissions

Assigning Permissions to Role

Via API:

Endpoint: POST /auth/roles/{role_id}/permissions

Requisição:

{
  "permission_id": 123
}

Ou adicione múltiplas permissões:

{
  "permission_ids": [123, 124, 125]
}

Exemplo: Criando uma Função "Especialista em Provisionamento"

Essa função pode visualizar clientes, gerenciar serviços e provisionar:

  1. Crie a função:

    POST /auth/roles
    {
      "name": "Provisioning_Specialist",
      "description": "Pode provisionar serviços e gerenciar serviços de clientes"
    }

  2. Adicione permissões:

    POST /auth/roles/45/permissions
    {
      "permission_ids": [
        1,   # view_customer
        20,  # view_customer_service
        21,  # create_customer_service
        22,  # update_customer_service
        30,  # view_provision
        31,  # create_provision
        40,  # view_inventory
        50,  # view_product
      ]
    }

Removendo Permissões de uma Função​

Via Interface da Web:

  1. Navegue até os detalhes da função
  2. Na lista de Permissões, clique no botão "X" ou "Remover" ao lado da permissão
  3. Confirme a remoção

Via API:

Endpoint: DELETE /auth/roles/{role_id}/permissions/{permission_id}

Exemplo:

DELETE /auth/roles/45/permissions/31

Isso remove a permissão create_provision da função.

Editando Detalhes da Função​

Atualize o nome ou a descrição da função:

Via Interface da Web:

  1. Navegue até Usuários e Funções → aba Funções
  2. Clique na função para editar
  3. Modifique o nome ou a descrição da função
  4. Clique em "Salvar"

Editing Role Details

Via API:

Endpoint: PUT /auth/roles/{role_id}

{
  "name": "Senior_Support",
  "description": "Equipe de suporte sênior com acesso total ao cliente"
}

Excluindo uma Função​

Aviso: Excluir uma função a remove de todos os usuários atribuídos. Certifique-se de que os usuários tenham funções alternativas ou perderão o acesso.

Via API:

DELETE /auth/roles/{role_id}

Melhor Prática: Em vez de excluir, considere arquivar ou renomear funções que não são mais necessárias.

Atribuindo Funções a Usuários​

Durante a Criação do Usuário:

Inclua a função na requisição de criação do usuário (veja "Adicionando Novos Usuários" acima).

Para Usuários Existentes:

Via Interface da Web:

  1. Navegue até Usuários e Funções → aba Usuários
  2. Clique no usuário para editar
  3. Na seção Funções, selecione/deselecione funções
  4. Clique em "Salvar"

Editing User Roles

Via API:

Atualize as funções do usuário:

Endpoint: PUT /auth/users/{user_id}

{
  "role": "Support,Finance"
}

Ou atribua uma única função a um usuário via endpoint de função:

Endpoint: POST /auth/roles/{role_id}/users/{user_id}

Visualizando Atribuições de Função​

Todos os usuários em uma função:

GET /auth/roles/{role_id}/users

Retorna uma lista de todos os usuários atribuídos a essa função.

Todas as funções de um usuário:

GET /auth/users/{user_id}

A resposta inclui um array roles com todas as funções atribuídas.

Gerenciando Senhas de Usuário​

OmniCRM fornece múltiplos métodos para gerenciamento de senhas, dependendo do contexto.

Redefinição de Senha pelo Usuário​

Usuários que esqueceram sua senha podem redefini-la por conta própria através da página de login:

  1. Clique em "Esqueceu a Senha" na página de login
  2. Insira o endereço de email - O sistema envia um email de redefinição de senha
  3. Verifique o email - O email contém um link seguro de redefinição com token (válido por 1 hora)
  4. Clique no link - Abre o formulário de redefinição de senha
  5. Insira a nova senha - Deve atender aos requisitos de complexidade de senha:
    • Mínimo de 8 caracteres
    • Pelo menos uma letra maiúscula
    • Pelo menos uma letra minúscula
    • Pelo menos um número
    • Pelo menos um caractere especial
  6. Enviar - A senha é imediatamente atualizada; o usuário pode fazer login com a nova senha

Fluxo da API:

  1. Solicitar redefinição:

    Endpoint: POST /auth/forgot_password

    {
      "email": "user@example.com"
    }

    O sistema gera um token de redefinição e envia um email.

  2. Redefinir com token:

    Endpoint: POST /auth/reset_password

    {
      "token": "abc123...",
      "new_password": "NewSecureP@ssw0rd!"
    }

Redefinição de Senha pelo Administrador​

Administradores podem redefinir a senha de um usuário sem exigir verificação por email. Isso define uma senha temporária que o usuário deve alterar no próximo login.

Via Interface da Web:

  1. Navegue até Usuários e Funções → Usuários
  2. Encontre o usuário e clique no botão "Redefinir Senha"
  3. Insira uma senha temporária
  4. Clique em "Redefinir"
  5. Notifique o usuário sobre sua senha temporária (via canal seguro)
  6. O usuário deve alterar a senha no próximo login

Via API:

Endpoint: POST /auth/users/{user_id}/admin_reset_password

Permissão Necessária: admin

Requisição:

{
  "new_password": "TempP@ssw0rd!",
  "force_change": true
}

Parâmetros:

  • new_password - Senha temporária a ser definida
  • force_change (opcional) - Se verdadeiro, o usuário deve alterar a senha no próximo login

Usuário Altera Sua Própria Senha​

Usuários autenticados podem alterar sua própria senha a partir de seu perfil:

Endpoint: POST /auth/change_password

Requisição:

{
  "current_password": "OldP@ssw0rd!",
  "new_password": "NewSecureP@ssw0rd!"
}

O sistema valida a senha atual antes de permitir a alteração.

Segurança da Senha​

  • As senhas são criptografadas usando bcrypt (segurança do werkzeug)
  • Nunca são armazenadas em texto simples
  • Tokens de redefinição expiram após 1 hora
  • Tentativas de login falhadas podem acionar bloqueio de conta (configurável)
  • O rastreamento do histórico de senhas impede reutilização (configurável)
  • Requisitos de complexidade são aplicados

Gerenciando Autenticação de Dois Fatores (2FA)​

OmniCRM suporta autenticação de dois fatores baseada em TOTP para segurança aprimorada. Administradores podem habilitar, desabilitar e redefinir 2FA para usuários.

OmniCRM 2FA nag popup shown to admin users

Habilitando 2FA para um Usuário​

Via Interface da Web:

  1. Navegue até Usuários e Funções → Usuários
  2. Clique no usuário para visualizar detalhes
  3. Na seção Segurança, clique em "Habilitar 2FA"
  4. O sistema gera:
    • Segredo TOTP (código QR exibido)
    • 10 códigos de backup (uso único)
  5. O usuário escaneia o código QR com o aplicativo autenticador (Google Authenticator, Authy, etc.)
  6. O usuário insere o código de verificação do aplicativo para confirmar a configuração
  7. O usuário salva os códigos de backup em local seguro
  8. 2FA agora está habilitado; necessário para todos os futuros logins

OmniCRM 2FA enrollment page

Via API:

  1. Gerar segredo TOTP:

    Endpoint: POST /2fa/enable/user/{user_id}

    Resposta:

    {
      "totp_secret": "JBSWY3DPEHPK3PXP",
      "qr_code_url": "otpauth://totp/OmniCRM:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=OmniCRM",
      "backup_codes": [
        "12345678",
        "23456789",
        "34567890",
        ...
      ]
    }

  2. Verificar configuração:

    Endpoint: POST /2fa/verify-setup/user/{user_id}

    {
      "code": "123456"
    }

    Retorna {"verified": true} em caso de sucesso.

Fluxo de Login 2FA​

Uma vez que 2FA está habilitado, o processo de login muda:

  1. O usuário insere nome de usuário e senha
  2. O sistema valida as credenciais
  3. Se válidas, solicita o código 2FA
  4. O usuário insere o código do aplicativo autenticador OU código de backup
  5. O sistema verifica o código
  6. Em caso de sucesso, o usuário é autenticado

OmniCRM 2FA Login

Códigos de Backup:

  • 10 códigos gerados durante a configuração do 2FA
  • Uso único apenas (consumidos após uso)
  • Usados se o aplicativo autenticador não estiver disponível
  • Podem ser regenerados pelo usuário ou administrador

Verificando Código 2FA​

Endpoint: POST /2fa/verify/user/{user_id}

{
  "code": "123456"
}

Aceita ambos:

  • Código TOTP (6 dígitos do aplicativo autenticador)
  • Código de backup (8 dígitos da lista de códigos de backup)

Regenerando Códigos de Backup​

Se um usuário esgotar os códigos de backup ou os perder, gere novos:

Via Interface da Web:

  1. Navegue até os detalhes do usuário
  2. Clique em "Regenerar Códigos de Backup"
  3. Exiba ou envie novos códigos para o usuário
  4. Os códigos antigos são invalidados

Via API:

Endpoint: POST /2fa/backup-codes/regenerate/user/{user_id}

Resposta:

{
  "backup_codes": [
    "98765432",
    "87654321",
    "76543210",
    ...
  ]
}

Redefinição 2FA pelo Administrador​

Se um usuário perder o acesso ao seu aplicativo autenticador e todos os códigos de backup, um administrador pode desabilitar e reabilitar 2FA.

Via Interface da Web:

  1. Navegue até Usuários e Funções → Usuários
  2. Clique no usuário
  3. Clique no botão "Redefinir 2FA"
  4. Confirme a redefinição
  5. 2FA é desabilitado; o usuário pode fazer login apenas com a senha
  6. Oriente o usuário a configurar 2FA novamente com um novo segredo

OmniCRM 2FA Reset

Via API:

Endpoint: POST /2fa/admin/disable/user/{user_id}

Permissão Necessária: admin

Isso desabilita completamente 2FA para o usuário:

  • Segredo TOTP limpo
  • Códigos de backup limpos
  • Flag is_2fa_enabled definida como falsa

O usuário pode então reabilitar 2FA para obter um novo segredo e códigos de backup.

Redefinição de 2FA pelo Usuário (Novo Dispositivo)​

Se um usuário obtiver um novo dispositivo, mas ainda tiver acesso aos códigos de backup:

Endpoint: POST /2fa/reset-for-new-device/user/{user_id}

{
  "backup_code": "12345678"
}

O sistema valida o código de backup, em seguida, gera um novo segredo TOTP e códigos de backup. O usuário pode configurar o aplicativo autenticador em seu novo dispositivo.

Melhores Práticas de 2FA​

  • Exigir 2FA para todo o pessoal administrativo e de suporte
  • Armazenar códigos de backup de forma segura (gerenciador de senhas ou nota segura)
  • Regenerar códigos de backup após usar vários
  • Usar aplicativos autenticadores respeitáveis (Google Authenticator, Authy, Microsoft Authenticator)
  • Documentar procedimentos de redefinição de 2FA para a equipe de suporte
  • Auditar o uso de 2FA - monitorar quais usuários têm 2FA habilitado

Atualizando Informações do Usuário​

Administradores podem atualizar os detalhes do usuário a qualquer momento.

Via Interface da Web:

  1. Navegue até Usuários e Funções → Usuários
  2. Clique no usuário para editar
  3. Modifique quaisquer campos editáveis:
    • Primeiro nome, nome do meio, último nome
    • Endereço de email (exige verificação)
    • Número de telefone
    • Funções
    • Vinculação de contato do cliente
  4. Clique em "Salvar"

Via API:

Endpoint: PUT /auth/users/{user_id}

{
  "first_name": "Jane",
  "last_name": "Doe-Smith",
  "email": "jane.doesmith@newcompany.com",
  "phone_number": "+61498765432",
  "role": "Support,Finance"
}

Mudanças de Email:

Quando o email é alterado, o novo email é marcado como pendente até ser verificado:

  • O campo pending_email armazena o novo email
  • Email de verificação enviado para o novo endereço
  • O usuário clica no link para verificar
  • O campo email é atualizado para o novo valor
  • A flag email_verified é definida como verdadeira

Excluindo Usuários​

OmniCRM utiliza exclusões suaves para usuários - eles são marcados como excluídos, mas não removidos do banco de dados. Isso preserva trilhas de auditoria e dados históricos.

Excluindo um Usuário​

Via Interface da Web:

  1. Navegue até Usuários e Funções → Usuários
  2. Encontre o usuário a ser excluído
  3. Clique no botão "Excluir"
  4. Confirme a exclusão
  5. O usuário é imediatamente desconectado e não pode fazer login novamente

Via API:

Endpoint: DELETE /auth/users/{user_id}

Permissão Necessária: admin

O Que Acontece:

  • A flag deleted é definida como True
  • O timestamp deleted_at é registrado
  • O usuário não pode fazer login
  • Todas as sessões ativas são invalidadas
  • O usuário ainda aparece nos logs de auditoria e registros históricos
  • Dados vinculados (contatos de clientes, atividades) são preservados

Visualizando Usuários Excluídos​

Filtrar usuários excluídos:

GET /auth/users/search?filters={"deleted":[true]}

Restaurando um Usuário Excluído​

Se um usuário foi excluído por engano, administradores podem restaurá-lo:

Endpoint: PUT /auth/users/{user_id}

{
  "deleted": false
}

Isso limpa a flag deleted e permite que o usuário faça login novamente.

Nota: A senha do usuário permanece inalterada, para que ele possa usar sua senha anterior.

Excluindo Permanentemente um Usuário​

Aviso: Isso é irreversível e remove todos os dados do usuário do banco de dados.

Não exposto via UI. Apenas disponível via acesso direto ao banco de dados por razões de conformidade (por exemplo, solicitações de exclusão de dados GDPR).

Melhores Práticas para Exclusão de Usuários​

  • Exclusão suave por padrão - Preserva trilhas de auditoria
  • Documentar razões para exclusão - Adicionar nota no log de atividades antes de excluir
  • Transferir propriedade - Reatribuir tickets abertos e tarefas do usuário antes de excluir
  • Revisar acesso - Garantir que nenhum processo crítico dependa do usuário
  • Arquivar dados - Exportar o histórico de trabalho do usuário, se necessário
  • Notificar equipes relevantes - Informar gerentes/colegas sobre a exclusão

Catálogo de Permissões​

As permissões geralmente seguem padrões CRUD:

  • view\_\* --- ler/navegar
  • create\_\* --- criar/adicionar
  • update\_\* --- editar/modificar
  • delete\_\* --- excluir/remover

Algumas entidades também incluem variantes "ver próprio ..." que restringem a visibilidade aos dados do próprio cliente/inquilino do usuário.

RBAC Permissions

Global / Administrativo​

  • admin --- Acesso administrativo total (gerenciar usuários, funções e permissões; acessar todos os endpoints protegidos).
  • can_impersonate --- Agir temporariamente como outro usuário (auditado; para suporte/resolução de problemas).

Clientes e Registros Relacionados​

  • Cliente
    • view_customer, create_customer, update_customer, delete_customer
    • Escopo próprio: ver próprio cliente
  • Site do Cliente
    • view_customer_site, create_customer_site, update_customer_site, delete_customer_site
    • Escopo próprio: ver próprio site do cliente
  • Contato do Cliente
    • view_customer_contact, create_customer_contact, update_customer_contact, delete_customer_contact
    • Escopo próprio: ver próprio contato do cliente
  • Atributo do Cliente (veja Atributos do Cliente)
    • view_customer_attribute, create_customer_attribute, update_customer_attribute, delete_customer_attribute
    • Escopo próprio: ver próprio atributo do cliente
  • Tag do Cliente (veja Tags do Cliente)
    • view_customer_tag, create_customer_tag, update_customer_tag, delete_customer_tag
    • Escopo próprio: ver própria tag do cliente
  • Serviço do Cliente
    • view_customer_service, create_customer_service, update_customer_service, delete_customer_service
    • Escopo próprio: ver próprio serviço do cliente
  • Atividade do Cliente
    • view_customer_activity, create_customer_activity, update_customer_activity, delete_customer_activity
    • Escopo próprio: ver própria atividade do cliente

Faturamento​

  • Cartão Stripe
    • view_customer_stripe_card, create_customer_stripe_card, update_customer_stripe_card, delete_customer_stripe_card
    • Escopo próprio: ver próprio cartão stripe do cliente
  • Transações
    • view_customer_transaction, create_customer_transaction, update_customer_transaction, delete_customer_transaction
    • Escopo próprio: ver própria transação do cliente
  • Faturas
    • view_customer_invoice, create_customer_invoice, update_customer_invoice, delete_customer_invoice
    • Escopo próprio: ver própria fatura do cliente

Comunicações​

  • view_communication, create_communication, update_communication, delete_communication
  • Escopo próprio: ver própria comunicação

Inventário e Modelos​

  • Inventário
    • view_inventory, create_inventory, update_inventory, delete_inventory
    • Escopo próprio: ver próprio inventário
  • Modelo de Inventário
    • view_inventory_template, create_inventory_template, update_inventory_template, delete_inventory_template
    • Escopo próprio: ver próprio modelo de inventário

Produtos​

  • view_product, create_product, update_product, delete_product

Transmissão de Células (CBC)​

  • view_cbc_message, create_cbc_message, update_cbc_message, delete_cbc_message

Provisionamento​

  • Provisionar
    • view_provision, create_provision, update_provision, delete_provision
    • Escopo próprio: ver próprio provisionamento
  • Evento de Provisionamento
    • view_provision_event, create_provision_event, update_provision_event, delete_provision_event

Acesso "Ver Próprio"​

As permissões "ver próprio ..." restringem as leituras (e opcionalmente edições, onde implementadas) aos dados associados ao próprio cliente/inquilino do usuário. Por exemplo, uma função Administrador de Cliente pode gerenciar os contatos, sites, faturas e serviços de seu inquilino, mas não pode ver outros inquilinos.

Designs Típicos de Funções​

Função Permissões Típicas Notas

Administrador do Sistema admin, opcionalmente can_impersonate; além de CRUD amplo conforme necessário Controle total sobre usuários/funções/permissões Suporte view_customer, view_customer_service, view_communication, view_provision; atualizações opcionais Adicione can_impersonate se permitido Finanças view_customer_invoice, view_customer_transaction, view_product; opcional create_customer_invoice Leitura pesada; escrita limitada Administrador de Cliente "ver próprio ..." em clientes, sites, contatos, serviços, inventário, faturas, transações, comunicações, provisionamento Gestão com escopo de inquilino Auditor Apenas Leitura Ampla view_* apenas Sem criar/atualizar/excluir

: Exemplo de Funções e Permissões Incluídas (resumo)

Gerenciando Funções e Permissões via API​

Todos os endpoints requerem permissão admin.

Listar permissões​

Endpoint: GET /auth/permissions

Criar uma permissão (raro)​

Endpoint: POST /auth/permissions

Corpo da Requisição:

{
    "name": "view_example",
    "description": "Acesso somente leitura a objetos de exemplo"
}

Listar funções​

Endpoint: GET /auth/roles

Criar uma função​

Endpoint: POST /auth/roles

Corpo da Requisição:

{
"name": "Support",
"description": "Equipe de suporte de nível 1"
}

Adicionar uma permissão a uma função​

Endpoint: POST /auth/roles/{role_id}/permissions

Corpo da Requisição:

{
  "permission_id": 123
}

Remover uma permissão de uma função​

Endpoint: DELETE /auth/roles/{role_id}/permissions/{permission_id}

Atribuindo Funções a Usuários​

Criar um usuário com função​

Endpoint: POST /auth/users

Corpo da Requisição:

{
  "username": "sara",
  "email": "sara@example.com",
  "password": "TempP@ssw0rd!",
  "first_name": "Sara",
  "last_name": "Ng",
  "phone_number": "+61...",
  "role": "Support"
}

Atualizar a função de um usuário​

Endpoint: PUT /auth/users/{user_id}

Corpo da Requisição:

{
  "role": "Finance"
}

Listar usuários (somente Admin)​

Endpoint: GET /auth/users

Impersonificação (Controlada)​

  • Necessário: can_impersonate ou admin

Iniciar impersonificação​

Endpoint: POST /auth/impersonate

Corpo da Requisição:

{ "user_id": 42 }

Parar impersonificação​

Endpoint: POST /auth/stop_impersonation

Melhores Práticas​

  • Menor privilégio primeiro. Comece com funções mínimas; adicione permissões conforme necessário.
  • Prefira "ver próprio ...". Use permissões com escopo de inquilino para funções voltadas para o cliente.
  • Mantenha funções estáveis. Atualize as permissões das funções quando as funcionalidades mudarem---não edite cada usuário.
  • Audite regularmente. Revise quem tem admin ou can_impersonate.

FAQ​

Um usuário pode ter várias funções? Sim. As permissões são aditivas.

Preciso de permissões personalizadas? Geralmente não. O catálogo embutido cobre a maioria das necessidades.

Como as regras "ver próprio ..." sabem o que é meu? Elas avaliam a ligação entre seu usuário/contato e seu cliente (inquilino).