Skip to main content

​
Permission

Cada Permission é um par action:resource que representa uma capacidade específica no sistema.

​
Formato

​
Catálogo de Permissions

O catálogo é controlado pelo DEVMOB e usado pelas superfícies Ops e BKO. Cada entrada declara em quais API surfaces (ops, bko) ela é aceita e a quais tipos de organização ela se aplica (Company, Cooperative ou Todas). O tipo de organização define a composição da role admin padrão criada com cada organização.

​
Organização & acesso

​
Plataforma e comunicação

​
Frota

​
Operações

Viagens, aprovações de rota e avaliações são capacidades operacionais da Cooperative. Uma Company não recebe essas permissions.

​
Vendas

​
Billing

​
Crédito corporativo

Permissions com escopo BKO não pertencem a nenhum tipo de organização. Elas só fazem sentido para roles INTERNAL.

​
Claims de acesso à API

Além das permissions do catálogo, existem três claims derivados — access:ops, access:bko e access:driver — que liberam o ingresso em cada API surface. Eles não são atribuídos como entidade própria: aparecem no Profile a partir dos vínculos ativos do usuário.

​
Role

Uma Role agrupa um conjunto de permissions sob um nome descritivo. As permissions atribuídas à Role vivem em RolePermission, não em um campo próprio da Role. Uma Role pode ter três tipos:
Roles ORGANIZATION são customizáveis por organização. Uma Cooperative pode ter uma role “Supervisor” com permissions diferentes da role “Supervisor” de outra Cooperative.

​
Role admin padrão

A role admin padrão é uma Role ENVIRONMENT compatível com o tipo da organização. No onboarding, o owner recebe uma Membership ACTIVE na nova organização apontando para essa role. Assim, organizações podem reutilizar roles padrão, enquanto roles ORGANIZATION continuam disponíveis para customização local. Na seleção de roles para convites, type=INTERNAL lista roles internas. Para uma organização, assignableToOrganizationId lista roles ENVIRONMENT globais e roles ORGANIZATION pertencentes à organização informada.

​
Atribuição via Membership

Membership é o ponto de encontro entre User, Organization e Role. Um usuário pode acumular mais de uma role na mesma organização.

​
Exemplo Prático

​
Verificação de Permissão

A cada requisição autenticada:
  1. O access token identifica o usuário.
  2. O Profile precisa estar ativo; caso contrário a requisição é rejeitada (403).
  3. Se a rota exige uma API surface, o claim access:{api} correspondente é conferido.
  4. As permissions efetivas são comparadas com a permission exigida pela ação.
O conjunto de permissions efetivas é a união dos claims derivados, das permissions das roles INTERNAL e das permissions das roles ENVIRONMENT/ORGANIZATION da organização ativa. Somente Memberships ACTIVE entram nessa composição. Um Profile resolve no máximo uma organização ativa.
Quando uma ação aceita múltiplas permissions, basta possuir uma delas, salvo quando a própria ação exige todas. A organização ativa restringe o escopo da operação.
Se o usuário não possui Membership ACTIVE na organização ativa, ou se o scope.permissionIds não contém a permission exigida, a requisição é rejeitada com 403 Forbidden.