Rôles et permissions
Imaginez que vous ayez affecté votre collègue minji.kim@example.com au Space de votre boutique de vêtements en ligne. Vous voulez bien lui confier l'enregistrement et la modification des produits, mais vous hésitez à lui laisser aussi le soin de supprimer un produit ou de le rendre public à l'extérieur. Cet ensemble de permissions qui définit « ce qu'un membre peut faire et ne peut pas faire au sein d'un Space » s'appelle le SpaceRole.
Plutôt que d'attribuer des permissions à chaque membre individuellement, le SpaceRole consiste à préparer à l'avance un ensemble de permissions, puis à le rattacher aux membres. Par exemple, une fois que vous avez créé un rôle « qui permet seulement de lire et de modifier les produits », il vous suffit de rattacher ce seul rôle aux collègues à qui vous confiez l'enregistrement des produits. Même lorsque le nombre de membres augmente, vous n'avez pas besoin de redéfinir les permissions à chaque fois en repartant de zéro.
Cette page présente d'abord ce qu'est un SpaceRole et quelles permissions il contient, puis vous fait créer vous-même un rôle « Responsable de l'enregistrement des produits » dans le Space de la boutique de vêtements.
Le rôle de Space est différent du rôle d'Organization
Dans WEEGLOO, il existe deux endroits où l'on définit les permissions. Comme il est facile de les confondre, traçons d'abord la frontière.
- Le rôle d'Organization (Owner, Admin, Member) est un niveau qui vaut pour toute l'entreprise. Il définit qui peut accomplir les tâches qui couvrent l'ensemble de l'Organization, comme inviter des membres ou créer un nouveau Space.
- Le SpaceRole est une permission au sein d'un Space précis. Il définit jusqu'où un membre peut aller dans la manipulation du contenu une fois entré dans cet espace de travail : créer des produits, les modifier, les publier.
Vous pouvez attribuer à un même collègue un SpaceRole différent selon le Space. Par exemple, dans le Space de la boutique en ligne, vous l'autorisez à aller jusqu'à modifier les produits, tandis que dans le Space des annonces internes, vous le limitez à la lecture seule. Cette page traite uniquement du SpaceRole. Le rôle d'Organization ainsi que l'invitation et l'affectation des membres sont traités dans Organization et Space.
Ce que contient un rôle : sur quoi, quelle action
Un SpaceRole contient « sur quel objet, quelle action, autoriser ou refuser ».
Les objets sur lesquels portent les permissions sont d'abord au nombre de quatre. Les trois suivants partagent le même ensemble d'actions ; le quatrième, Script, a des actions différentes et est traité à part plus loin.
- Content Type : le modèle de formulaire, comme un produit ou une annonce.
- Content : chacun des produits créés à partir de ce modèle.
- Media : les fichiers téléversés comme des photos ou des vidéos.
Les actions que l'on peut autoriser ou refuser pour chaque objet sont les suivantes.
Les actions s'affichent en anglais à l'écran. Voici la signification de chacune.
| Action (libellé à l'écran) | Ce qu'elle fait |
|---|---|
| Read | Voir la liste et le contenu |
| Create | Créer un nouvel élément |
| Edit | Modifier et enregistrer un élément existant |
| Delete | Supprimer |
| Publish | Publier pour que l'élément soit rendu public (transmis) à l'extérieur |
| Unpublish | Retirer la publication et arrêter la diffusion publique |
| Archive | Faire passer en état d'archive |
| Unarchive | Restaurer depuis l'archive |
| All actions | Autoriser d'un coup toutes les actions ci-dessus |
Pour reprendre l'exemple de la boutique de vêtements, le rôle « Responsable de l'enregistrement des produits » autorise sur le Content (les produits) les actions Read, Create et Edit, sans y inclure Delete ni Publish. Ainsi, le collègue peut créer et modifier des produits, mais ne peut ni les supprimer ni les rendre publics à l'extérieur.
Ce qu'est Publish et la façon dont un élément publié est rendu public (transmis) à l'extérieur sont traités en détail dans États et publication.
Autoriser et refuser
L'écran du rôle comporte séparément une liste Allowed et une liste Denied. Le principe est d'ajouter une à une, dans la liste Allowed, les actions que l'on veut rendre possibles. Point important : toute action qui n'est pas ajoutée à la liste des actions autorisées est automatiquement refusée. Il vous suffit donc d'ajouter aux actions autorisées uniquement celles que vous voulez confier au collègue ; le reste est bloqué sans que vous ayez à le bloquer séparément.
La liste Denied est un garde-fou à utiliser « lorsque vous voulez autoriser largement, mais bloquer en exception une partie précise ». Lorsqu'une même action figure à la fois dans les autorisations et dans les refus, le refus l'emporte toujours.
Restreindre la portée à un type précis ou à une personne précise
Lorsque vous autorisez une action, vous pouvez restreindre cette autorisation à une seule catégorie ou à une condition précise. Par exemple, les restrictions suivantes sont possibles.
- À un seul type : s'appliquer uniquement au Content Type « Produit », sans s'appliquer aux autres Content Type.
- Uniquement à ce que la personne a créé elle-même : permettre au membre de manipuler seulement le Content qu'il a créé lui-même, sans pouvoir toucher à ce que les autres ont créé.
- Uniquement à ce qui porte un Tag précis : s'appliquer seulement au Content ou au Media portant un Tag défini.
Si vous ne restreignez pas la portée, l'action s'applique à l'ensemble de l'objet concerné. Par exemple, si vous autorisez la lecture du Content sans la restreindre, le membre peut lire tous les Content ; si vous la restreignez au Content Type « Produit », il ne peut lire que les produits.
Ce qu'est un Tag est traité dans Tag.
Permissions d'exécution et de gestion des Script
Au-delà des trois objets ci-dessus, un SpaceRole contient aussi des permissions sur les Script. Un Script est un point de terminaison backend, appelé par votre frontend et créé sans code serveur (voir Script). Il possède une action Execute (exécuter) que le Content et le Media n'ont pas.
- Execute : permet d'exécuter (d'appeler) ce Script. Votre frontend, ou un membre inscrit, a besoin de cette permission pour appeler un Script.
- Read, Create, Edit, Delete : les permissions de gestion pour consulter, créer, modifier et supprimer un Script.
Vous pouvez restreindre selon l'auteur, de sorte qu'un membre ne manipule « que le Script qu'il a créé lui-même ». Il n'y a pas d'action de publication, car un Script n'est pas une ressource que l'on publie. Pour les membres inscrits à votre produit (ServiceUser), vous n'ouvrez en général que Execute, car la création et la modification des Script sont assurées par les utilisateurs du studio de contenu.
Le format exact des règles de permissions est traité dans les références d'API SpaceRole et ServiceUserRole.
Le rôle décide aussi si l'on peut modifier les paramètres du Space
Jusqu'ici, il s'agissait des permissions qui portent sur le contenu et sur les Script. Un rôle contient encore une autre liste, de nature différente. Elle indique si l'on peut modifier les paramètres du Space.
Pour revenir à l'exemple de la boutique de vêtements, vous voulez bien confier à votre collègue l'enregistrement des produits, mais vous ne voudrez sans doute pas lui confier en plus l'ajout d'une nouvelle Locale ou la délivrance d'un token destiné à un site externe. C'est cette liste qui définit qui peut effectuer ces tâches de configuration du Space.
Contrairement aux permissions précédentes, cette liste ne comporte ni action ni restriction de portée. Un élément activé donne accès au paramètre correspondant ; un élément laissé désactivé n'y donne pas accès. Vous les activez et les désactivez dans l'onglet Permissions de l'écran où vous créez ou modifiez un rôle. Activer Tous les Permissions de gestion en haut active d'un coup tous les éléments en dessous, et les activer un par un affiche également cet interrupteur comme activé. Voici les éléments que vous pouvez activer.
| Élément | Ce que son activation permet de faire |
|---|---|
| Gérer les informations du Space | Modifier le nom et la description du Space |
| Gérer les adhésions | Ajouter et retirer des membres de ce Space, et changer leur rôle |
| Manage Roles | Créer et modifier des rôles, comme vous le faites sur cette page |
| Manage Delivery Access Tokens | Délivrer et gérer les tokens en lecture seule |
| Manage Space Access Tokens | Délivrer et gérer les tokens qui lisent et écrivent |
| Manage Locales | Ajouter une langue ou changer la langue par défaut |
| Manage Email Accounts | Enregistrer le compte expéditeur utilisé pour envoyer les e-mails |
| Gérer les apps | Récupérer une application sur la place de marché et l'installer |
| Manage Tags | Créer, modifier et supprimer des Tag |
| Manage Web Hostings | Déployer un site et y relier un domaine |
| Manage ServiceLogin | Configurer la connexion et les permissions des membres qui s'inscrivent à votre produit |
| Manage Webhooks | Créer un Webhook et consulter l'historique des appels |
| Manage Schedulers | Créer un Scheduler et consulter l'historique des exécutions |
| Consulter la supervision | Voir le stockage et le trafic consommés par ce Space |
Notez bien que les deux types de tokens forment deux éléments distincts. Vous pouvez autoriser la délivrance du seul Delivery Access Token, en lecture seule, et empêcher celle du Space Access Token, qui lit et écrit. C'est ainsi que vous répartissez les droits lorsque vous voulez laisser votre collègue délivrer lui-même le token de lecture destiné à un site public, tout en réservant à un administrateur la création du token qui va jusqu'à l'écriture.
Manage Schedulers ne suffit pas à lui seul. Lorsque vous créez ou modifiez un Scheduler, vous devez aussi détenir la permission Execute sur le Script qu'il exécutera (voir Avec les autorisations de qui il s'exécute).
Si vous n'activez aucun élément, ce rôle devient un rôle qui ne manipule que du contenu. C'est le cas du rôle « Responsable de l'enregistrement des produits » que vous allez créer plus loin. Il peut enregistrer et modifier des produits, mais ne peut toucher à aucun paramètre du Space.
Le rôle Administrator fourni à la création d'un Space
Lorsque vous créez un nouveau Space, un rôle nommé Administrator est automatiquement créé en même temps. Ce rôle est le rôle au plus haut niveau de permissions, capable de tout manipuler au sein du Space. La personne qui a créé le Space commence en détenant ce rôle Administrator.
Le rôle Administrator est un rôle préparé par le système : il ne peut être ni modifié ni supprimé. Si vous voulez donner à un collègue des permissions restreintes, plutôt que de modifier l'Administrator, créez un nouveau rôle distinct comme ci-dessous et attribuez-le-lui.
Créer le rôle « Responsable de l'enregistrement des produits »
Vous allez maintenant créer vous-même, dans le Space de la boutique de vêtements, le rôle « Responsable de l'enregistrement des produits » à donner à un collègue. Ce rôle pourra faire les actions Read, Create et Edit sur les produits (Content), mais ne pourra ni les supprimer ni les publier.
- Dans le menu de gauche, cliquez sur Roles et Permissions.
- Cliquez sur le bouton Créer en haut à droite de la liste.
- Dans le champ du nom de l'onglet Role detail, saisissez
Responsable de l'enregistrement des produits. Le champ de description peut rester vide.
Vous définissez ensuite les actions que ce rôle peut faire sur les produits (Content). Vous ajoutez chaque action comme une règle, une par ligne, dans la liste Allowed, et vous choisissez sur la même ligne la portée d'application (Content Type).
- Allez dans l'onglet Content.
- Sous Allowed, cliquez sur + pour ajouter une ligne de règle.
- Sur cette ligne, choisissez Read comme action et « Produit » comme Content Type à appliquer. (Si vous laissez les champs auteur et Tag sur « Any… », la règle s'applique à l'ensemble.)
- De la même manière, ajoutez aussi une règle Create et une règle Edit, une par ligne. Sur les trois lignes, laissez « Produit » comme Content Type.
- N'ajoutez pas Delete (suppression) ni Publish (publication) aux actions autorisées. Comme toute action non ajoutée aux autorisations est automatiquement refusée, le collègue ne pourra ni supprimer les produits ni les rendre publics à l'extérieur.
- Cliquez sur le bouton Enregistrer en haut à droite.
Lorsque « Responsable de l'enregistrement des produits » apparaît dans la liste, le rôle a été créé. Il s'affiche aux côtés de l'Administrator présent dès le départ.
Donner le rôle créé à un collègue
Ce n'est pas parce que vous avez créé un rôle qu'il s'applique automatiquement à quelqu'un. Pour prendre effet, le rôle créé doit être rattaché à un membre.
Au moment d'affecter un collègue à un Space, vous choisissez en même temps le rôle qu'il aura au sein de ce Space ; c'est là que vous choisissez le « Responsable de l'enregistrement des produits » que vous venez de créer. Si le collègue est déjà entré dans le Space, vous pouvez aussi modifier son rôle depuis la liste des membres pour l'appliquer. Vous pouvez également donner plusieurs rôles à un même membre. Dans ce cas, les actions autorisées par chacun des rôles se cumulent : si une action est autorisée par l'un des rôles, le membre peut la faire. (Le fait que le refus l'emporte sur l'autorisation ne vaut qu'à l'intérieur d'un même rôle. Même si une action est refusée dans un rôle, elle reste possible si un autre rôle l'autorise.)
Les étapes concrètes pour affecter un membre à un Space et choisir son rôle sont traitées dans Organization et Space.
Ce qu'il faut faire ensuite
- Organization et Space : affecter un collègue à un Space et lui rattacher le rôle que vous venez de créer.
- Tokens : traite des tokens d'accès qui permettent non pas à une personne, mais à un site externe ou à un programme, de lire ou d'écrire le contenu. Le rôle que vous créez ici se rattache aussi aux tokens. Rattaché à un Delivery Access Token, le rôle définit la portée de lecture de ce token ; rattaché à un Space Access Token, il en définit la portée de lecture et d'écriture. Les permissions de délivrance et de gestion étant distinctes pour les deux tokens, vous pouvez aussi n'en activer qu'une seule dans la liste paramètres du Space ci-dessus.
- Référence de l'API : traite des spécifications techniques, comme le format des requêtes, nécessaires lorsque vous créez un rôle ou manipulez les règles de permissions directement depuis un programme.