Skip to main content
Um papel é um conjunto de permissões: quais objetos um app pode ler ou gravar, quais campos ele pode ver e quais recursos em nível de plataforma ele pode usar. Todas as funções de lógica e os componentes de front-end de cada app herdam as permissões do papel marcado com defineApplicationRole() (consulte O papel padrão da função abaixo).
src/roles/restricted-company-role.ts

Segurança ao nível da linha

As permissões de objeto e de campo determinam quais objetos e campos uma função pode acessar. Predicados de permissão ao nível da linha vão além e determinam quais registros uma função pode ver e atuar sobre — por exemplo, uma função de autoatendimento em que cada usuário externo vê apenas seus próprios registros. Declare predicados com rowLevelPermissionPredicates na função. Como o restante do manifesto, cada predicado carrega seu próprio universalIdentifier e faz referência a um objeto e a um campo por seus respectivos universalIdentifier, a um operand e, opcionalmente, a um campo de workspaceMember cujo valor é injetado no momento da consulta — assim, você pode expressar: “a relação de proprietário do registro é o membro de workspace atual”:
src/roles/partner-role.ts
Como os predicados são enviados no manifesto, eles são criados, atualizados e removidos junto com a função em cada instalação e atualização — não há uma etapa pós-instalação separada para manter em sincronia.

Combinando predicados com grupos

Por padrão, os predicados de uma função são combinados com AND. Para combinar alguns deles com OR (ou para aninhar a lógica), declare uma entrada rowLevelPermissionPredicateGroups e faça cada predicado apontar para ela por meio de predicateGroupUniversalIdentifier. Essa função permite que um parceiro veja uma Oportunidade da qual ele é proprietário ou pela qual é o ponto de contato:
src/roles/partner-opportunities-role.ts
Notas:
  • Dê a cada predicado e grupo um universalIdentifier estável (qualquer uuid) — ele identifica a entidade entre atualizações, e os predicados referenciam os grupos por meio dele.
  • Os predicados podem referenciar objetos e campos pertencentes ao seu app ou aos objetos padrão da Twenty.
  • A segurança ao nível da linha é aplicada para os workspaces em planos que a incluem; os predicados ainda são sincronizados em outros planos; eles simplesmente não são aplicados.

Papel de função padrão

Ao criar um novo app com o scaffold, a CLI cria um arquivo de papel padrão declarado com defineApplicationRole():
src/roles/default-role.ts
defineApplicationRole() é um wrapper leve em torno de defineRole() que sinaliza o papel usado como padrão do seu app no momento da instalação. A validação é idêntica à de defineRole, mas o pipeline de build conecta automaticamente seu universalIdentifier ao defaultRoleUniversalIdentifier do manifesto do app — assim, você não precisa referenciá-lo em defineApplication. Notas:
  • Exatamente um defineApplicationRole(...) é permitido por app — o build do manifesto falhará se encontrar mais de um.
  • Use defineRole() (não defineApplicationRole()) para quaisquer papéis adicionais que o seu app forneça.
  • Definir defaultRoleUniversalIdentifier explicitamente em defineApplication() ainda é compatível para retrocompatibilidade, mas foi preterido em favor de defineApplicationRole().

Melhores Práticas

  • Comece a partir do papel gerado pelo scaffold e, em seguida, restrinja-o progressivamente — o padrão concede amplo acesso de leitura, o que raramente é o que você quer em produção.
  • Substitua objectPermissions e fieldPermissions pelos objetos e campos de que suas funções realmente precisam.
  • permissionFlagUniversalIdentifiers controlam o acesso a recursos em nível de plataforma. Mantenha-os no mínimo necessário.
  • Veja um exemplo funcional: hello-world/src/roles/function-role.ts.