Permissions

Identité, rôles, ensembles d'autorisations, accès aux enregistrements et sécurité des champs — l'intégralité du modèle d'accès sur une seule page.

ObjectOS dispose d'un modèle d'accès en couches inspiré des principes qui ont fait leurs preuves dans les logiciels d'entreprise depuis deux décennies : identité → rôles → ensembles d'autorisations → accès aux enregistrements → sécurité des champs. Chaque couche répond à une question différente, et vous pouvez ignorer celles dont vous n'avez pas besoin.

Le modèle en un seul diagramme

Authentication       Who is the caller?
        ↓
Identity             Which user/org/membership is active?
        ↓
Roles                Where do they sit in the hierarchy?
        ↓
Permission sets      What CAN they do — apps, objects, fields, system?
        ↓
Record access        WHICH records can they touch?
        ↓
Field security       For those records, which FIELDS are readable / writable?

Chaque couche est appliquée par le plugin de sécurité. Vous pouvez utiliser uniquement les ensembles d'autorisations (sans rôles, sans règles de partage) pour des applications simples et ajouter le reste à mesure que le besoin apparaît.

Couche 1 — Identité

Les objets d'identité résident dans la base de données de votre projet. Les plus importants :

Objet	Ce qu'il représente
`sys_user`	Une personne ou un compte de service pouvant s'authentifier
`sys_organization`	Limite de locataire / espace de travail (applications multi-locataires)
`sys_member`	L'appartenance d'un utilisateur à une organisation (rôle attribué par appartenance)
`sys_business_unit`, `sys_team`	Structure organisationnelle facultative pour les règles de partage
`sys_invitation`	Invitation en attente d'acceptation
`sys_session`	Session authentifiée active
`sys_api_key`	Identifiant programmatique de longue durée lié à un utilisateur

Dans un déploiement multi-locataire :

Les utilisateurs sont délimités à la base de données du projet.
Les sessions sont délimitées au nom d'hôte du projet.
Les vérifications au niveau des lignes utilisent l'organisation et les autorisations de l'utilisateur courant.
Les utilisateurs du plan de contrôle ne sont pas automatiquement des utilisateurs métier — ils doivent être mappés via le SSO de la plateforme ou un provisionnement explicite.

Vous créez/gérez ces éléments depuis la Console (/_console/) à l'exécution, ou vous les initialisez dans objectstack.config.ts pour les nouveaux environnements.

Couche 2 — Rôles

Les rôles modélisent l'organigramme (CFO → Responsable financier → Analyste). Ils existent principalement pour que les règles de partage et les rapports puissent exprimer des choses comme « le responsable du propriétaire de l'enregistrement ». Utilisez les rôles lorsque vous avez besoin d'un accès hiérarchique ; ignorez-les pour les équipes à structure plate.

Voir Rôles.

Couche 3 — Ensembles d'autorisations

Les ensembles d'autorisations constituent le principal moyen d'accorder des capacités. Ils s'attachent aux utilisateurs directement ou via les rôles.

Ce qu'ils accordent

Type	Exemples
Accès aux applications	Ouvrir le CRM, ouvrir le portail de support
Permissions sur les objets	Créer / lire / mettre à jour / supprimer les enregistrements d'un objet
Permissions sur les champs	Lire ou mettre à jour des champs spécifiques
Permissions système	Accéder à la Console, exécuter des rapports, exporter des données, consulter le journal d'audit
Permissions d'intégration	Utiliser des clés API, configurer des webhooks, exécuter des actions d'administration

Indicateurs de permission sur les objets

Voici les noms exacts des indicateurs vérifiés par le plugin de sécurité :

Indicateur	Signification
`allowRead`	Lire les enregistrements que l'utilisateur peut voir via l'accès aux enregistrements
`allowCreate`	Créer de nouveaux enregistrements
`allowEdit`	Mettre à jour les enregistrements que l'utilisateur peut voir
`allowDelete`	Supprimer les enregistrements que l'utilisateur peut voir
`viewAllRecords`	Lire chaque enregistrement de l'objet, en ignorant les règles d'accès aux enregistrements
`modifyAllRecords`	Mettre à jour/supprimer chaque enregistrement ; implique `viewAllRecords`

viewAllRecords et modifyAllRecords sont des privilèges de super-utilisateur à l'échelle du locataire pour cet objet. Réservez-les à des ensembles d'autorisations administratifs explicites et tenez-les à l'écart de tout rôle destiné aux utilisateurs.

Voir Ensembles d'autorisations.

Couche 4 — Accès aux enregistrements

Pour les utilisateurs sans viewAllRecords, quelles lignes peuvent-ils voir ?

Le modèle prend en charge :

La propriété implicite (les lignes que l'utilisateur a créées ou possède)
Les règles de partage (déclaratives — « l'équipe A voit les enregistrements de l'équipe A »)
Les partages explicites (lignes sys_record_share — partages ponctuels)
La délimitation par organisation (l'organization_id de la ligne correspond à l'organisation de l'utilisateur)

Voir Accès aux enregistrements.

Couche 5 — Sécurité des champs

Même lorsqu'un utilisateur peut voir un enregistrement, des champs individuels peuvent être :

Masqués — le champ est retiré des réponses de l'API et de l'interface.
En lecture seule — le champ est renvoyé mais rejeté en écriture.

La sécurité des champs s'applique par objet + par ensemble d'autorisations. Usage typique :

Masquer salary sur sys_user pour toute personne en dehors des RH.
Rendre external_account_id lisible mais non modifiable pour les commerciaux du support.

Elle est appliquée par le même évaluateur que les permissions sur les objets, de sorte qu'elle s'applique uniformément à REST, ObjectQL et la Console.

Par où commencer

Si vous construisez …	Utilisez
Un outil interne pour une seule équipe	Uniquement des ensembles d'autorisations
Une application multi-équipes où les responsables consultent des rapports	Rôles + ensembles d'autorisations
Une application de type SaaS multi-locataire	Délimitation par organisation + ensembles d'autorisations
Une application réglementée avec des données personnelles (PII)	Ajouter la sécurité des champs par-dessus
Une application complexe de type CRM	L'ensemble complet de la pile

Diagnostiquer et auditer

/_console/ affiche les permissions effectives de tout utilisateur telles qu'elles sont évaluées.
Le journal d'audit (sys_audit_log) enregistre les modifications sensibles aux permissions — octrois, attributions de rôles, modifications d'ensembles d'autorisations.
Les requêtes refusées consignent la règle qui a échoué (permission sur l'objet, accès à l'enregistrement ou sécurité des champs), afin que le support puisse répondre rapidement à la question « pourquoi ne puis-je pas voir ceci ? ».

On this page