Panoramica
Un ruolo è un insieme di permessi: quali oggetti un’app può leggere o scrivere, quali campi può vedere e quali funzionalità a livello di piattaforma può usare. Tutte le funzioni di logica e i componenti front-end di ogni app ereditano i permessi del ruolo contrassegnato condefineApplicationRole() (vedi The default function role di seguito).
src/roles/restricted-company-role.ts
SystemPermissionFlag.USER_APPS e SystemPermissionFlag.WORKSPACE_APPS
sono disponibili in twenty-sdk dalla versione 2.54; le versioni precedenti li denominano
CONNECTED_ACCOUNTS e APPLICATIONS. I vecchi nomi sono alias deprecati
per gli stessi flag e un ruolo mantiene ogni flag una sola volta. L’enumerazione di
SystemPermissionFlag, ad esempio con Object.keys, elenca ancora i vecchi
nomi. L’API segnala inoltre questi flag con le loro vecchie chiavi, ad esempio in
currentUserWorkspace.permissionFlags.Sicurezza a livello di riga
Le autorizzazioni a livello di riga richiedono il piano Organization o superiore — consulta i prezzi. Ciò che accade con un piano senza il diritto è trattato nelle note alla fine di questa sezione. Le autorizzazioni sugli oggetti e sui campi determinano quali oggetti e campi un ruolo può gestire. I predicati di autorizzazione a livello di riga vanno oltre e determinano quali record un ruolo può vedere e su cui può agire — per esempio, un ruolo self-service in cui ogni utente esterno vede solo i propri record. Dichiara i predicati conrowLevelPermissionPredicates sul ruolo. Come il resto del manifest,
ogni predicato ha il proprio universalIdentifier e fa riferimento a un oggetto e a un campo tramite il loro
universalIdentifier, un operand e (facoltativamente) un campo workspaceMember il cui valore viene iniettato
al momento della query — così puoi esprimere “la relazione di proprietario del record è l’attuale membro dello spazio di lavoro”:
src/roles/partner-role.ts
Combinare i predicati con i gruppi
Per impostazione predefinita, i predicati di un ruolo sono combinati conAND. Per combinarne alcuni con OR (o per annidare la logica), dichiara una voce rowLevelPermissionPredicateGroups e collega ogni predicato ad essa tramite predicateGroupUniversalIdentifier. Questo ruolo consente a un partner di vedere un’Opportunità di cui è proprietario
o per cui è il punto di contatto:
src/roles/partner-opportunities-role.ts
- Assegna a ogni predicato e gruppo un
universalIdentifierstabile (qualsiasi uuid) — identifica l’entità attraverso gli aggiornamenti e i predicati fanno riferimento ai gruppi tramite esso. - I predicati possono fare riferimento a oggetti e campi di proprietà della tua app o degli oggetti standard di Twenty.
- La sicurezza a livello di riga è applicata agli spazi di lavoro con il piano Organization o superiore. Con gli altri piani, i predicati dichiarati in un manifesto dell’app vengono comunque sincronizzati, semplicemente non vengono applicati.
- L’API Metadata si comporta qui in modo diverso rispetto al manifesto: senza il diritto,
upsertRowLevelPermissionPredicatesviene rifiutato conROW_LEVEL_PERMISSION_FEATURE_DISABLEDanziché essere sincronizzato. Uno spazio di lavoro con un piano che non include la sicurezza a livello di riga non può quindi creare predicati al di fuori di un manifesto dell’app, anche se il camporowLevelPermissionPredicatesè presente nel tipoRolequando si esegue l’introspezione dello schema.
Ruolo funzione predefinito
Quando esegui lo scaffolding di una nuova app, la CLI crea un file di ruolo predefinito dichiarato condefineApplicationRole():
src/roles/default-role.ts
defineApplicationRole() è un leggero wrapper attorno a defineRole() che contrassegna il ruolo usato come predefinito per la tua applicazione al momento dell’installazione. La convalida è identica a defineRole, ma la pipeline di build collega automaticamente il suo universalIdentifier al defaultRoleUniversalIdentifier del manifest dell’applicazione — quindi non è necessario farvi riferimento in defineApplication.
Note:
- È consentita esattamente una chiamata a
defineApplicationRole(...)per app — la build del manifest avrà esito negativo se ne trova più di una. - Usa
defineRole()(nondefineApplicationRole()) per qualsiasi ruolo aggiuntivo fornito dalla tua app. - L’impostazione esplicita di
defaultRoleUniversalIdentifierindefineApplication()è ancora supportata per retrocompatibilità, ma è deprecata a favore didefineApplicationRole(). Può anche indicare un ruolo che la tua app non definisce, come il ruolo predefinito integrato dell’applicazione personalizzata dello spazio di lavoro mantenuto datwenty app pull; la compilazione non può quindi verificare quel ruolo, perciò deve esistere nello spazio di lavoro di destinazione. - Un ruolo a cui possono essere assegnati membri dello spazio di lavoro o chiavi API (
canBeAssignedToUsersocanBeAssignedToApiKeys, entrambitruese omessi) è un ruolo personalizzato e richiede il piano Organization o superiore: con altri piani l’installazione viene rifiutata. Mantieni entrambi sufalseper i ruoli che vengono eseguiti solo dalla tua app e dai relativi agenti.
Ruoli agente
Il ruolo dell’applicazione è ciò che un workspace esamina quando installa la tua app, quindi deve coprire tutto ciò che l’app stessa può fare. Qualsiasi ruolo assegnato a un agente tramiteroleUniversalIdentifier in defineAgent() non deve concedere più del ruolo dell’applicazione: nessuna azione su oggetti, accesso ai campi, flag di autorizzazione o ambito a livello di riga che il ruolo dell’applicazione non possiede. In caso contrario, la compilazione non riesce e viene visualizzato un errore che elenca le concessioni in eccesso. I ruoli che la tua app fornisce per i membri del workspace o le chiavi API non sono soggetti a questa regola, poiché l’app non viene mai eseguita con essi. Il controllo richiede il ruolo dell’applicazione nel codice sorgente della tua app, quindi viene ignorato quando il ruolo predefinito è definito altrove.
Migliori Pratiche
- Parti dal ruolo generato dallo scaffold, poi restringilo progressivamente: il ruolo predefinito concede un ampio accesso in lettura, che raramente è ciò che vuoi in produzione.
- Sostituisci
objectPermissionsefieldPermissionscon gli oggetti e i campi di cui le tue funzioni hanno realmente bisogno. permissionFlagUniversalIdentifierscontrollano l’accesso alle funzionalità a livello di piattaforma. Mantienili al minimo.- Un flag di autorizzazione dichiarato dalla tua app con
definePermissionFlag()ha unpermissionType:'tool'(il valore predefinito) per una funzionalità che può essere concessa a un agente o a un utente,'settings'per un flag che sblocca un’area delle impostazioni. - Vedi un esempio di lavoro:
examples/hello-world/src/roles/default-role.ts.