Docs › Fundamentos

Tipos de App e tenancy

appKind, disponibilidade, modo de acesso e tenancy — a matriz canônica de arquiteturas do Ecossistema Oon.

Tipos de App (appKind)

appKind Papel no ecossistema Exemplo
member-central Central publicada para um tenant, licença e ambiente. O caso mais comum. Central de Compras, Central Financeira
root-central Central de Ativações — a raiz de confiança do Ecossistema. Central de Ativações
portal-cockpit Portal ou cockpit transversal. Meus Apps

O appKind não limita a customização: páginas, componentes, layouts e temas locais funcionam em todos os tipos.

Três dimensões independentes

  • Disponibilidade — finalidade: system, common, self, licensed.
  • Tenancy — isolamento: none, single_tenant, multi_tenant.
  • Implantação — derivada: none → singleton, single_tenant → dedicated, multi_tenant → shared.

self/single_tenant é o uso da própria organização proprietária, sem licença comercial artificial. licensed admite exclusivo e compartilhado; clientes multi-tenant usam somente Produção. Licenciamento, capacidade e autorização comercial pertencem à Central, nunca ao código do App.

Matriz canônica

Categoria tenancyModel availability accessMode authorizationMode deployment
App próprio da organização single_tenant self explicit_users rbac dedicated
App licenciado single-tenant single_tenant licensed explicit_users rbac dedicated
App licenciado multi-tenant multi_tenant licensed explicit_users rbac shared ou dedicated
App comum tenant-aware multi_tenant common tenant_members rbac shared
App global da Plataforma none common authenticated_users rbac singleton
Central root none system explicit_users rbac singleton

Regras de validação

  • root-central exige none/system/explicit_users/rbac/singleton.
  • Apps member não podem usar availability=system.
  • tenant_members exige um App tenant-aware (não none).
  • authenticated_users exige tenancyModel=none, availability=common, authorizationMode=rbac e singleton. Não é acesso público: exige identidade Oon ativa.
  • single_tenant não pode usar shared.
  • deploymentMode legado só é aceito quando concorda com o derivado; hybrid é rejeitado.

Escopo de dados por model

Independente do tenancy do App, cada model declara seu scope:

scope Isolamento
legacy (padrão) Sem filtro de linha.
system Dados do sistema, sem filtro de linha.
tenant Campo tenantId interno, obrigatório, imutável e indexado; filtrado pelo contexto autenticado.
user tenantId (quando o App tem tenant) + usuarioId; cada usuário vê só os seus. 
defineModel({ name: "Pessoa", scope: "tenant", schema: { /* ... */ } });

Apps globais e tenant-alvo

Apps com tenancyModel=none não montam TenantProvider, não restauram tenant do storage e não consomem o parâmetro tenant. Uma sessão global não contém tenantId, e o header x-oon-tenant-id não a transforma em sessão de tenant.

Operações administrativas sobre uma organização usam um identificador próprio, como targetTenantId, convertido pelo backend no header x-oon-target-tenant-id do contrato administrativo. Esse alvo é apenas um seletor — o backend revalida usuário, tenant, membership, RBAC, entitlement e quota.

Ambientes de Apps licenciados single-tenant

O proprietário (A) mantém os deployments de Dev, HML e Produção. Produção usa o tenant de dados do cliente (B); Dev/HML usam o tenant de dados de A, tanto para membros de A quanto para usuários autorizados de B — sem criar membership de B em A.

  • req.accessContext.tenantId é o contexto de dados; authorizationTenantId identifica a organização da concessão.
  • A Central revalida licença, grant, política e revisão do ambiente em cada requisição protegida; o Core não mantém cache positivo de autorização.
  • Dev/HML são fechados para B por padrão e exigem liberação independente.
  • Publicação, promoção, rollback e aceite técnico de HML são exclusivos de A.