Accorder à un rôle l’accès aux enregistrements

Objectif

Décider de ce que chaque rôle peut faire avec les enregistrements d’un environnement — dans le cadre de la solution qui livre l’application, pour que le même accès atteigne Test et Prod.

Prérequis

• Vous êtes connecté au Centre de contrôle d’administration.
• Une solution est ouverte (voir Créer une solution).
• Les tables auxquelles vous voulez accorder l’accès existent dans l’environnement. Une table est créée avec ses données derrière elle : chaque table que vous voyez est donc une table à laquelle vous pouvez accorder l’accès.

Deux questions, pas une

Chaque ligne d’un rôle répond à deux questions distinctes, et comprendre cette séparation, c’est comprendre l’essentiel de cet écran :

• Une autorisation — que peuvent-ils faire ? Create, Read, Update, Delete sur une table.
• Une stratégie — sur quels enregistrements ? De Mes enregistrements, en passant par Mon unité et en dessous, jusqu’à Tous les enregistrements.

C’est pourquoi chaque cellule de la grille est une liste déroulante plutôt qu’une case à cocher : une case à cocher ne peut répondre qu’à la première question.

Attribuer le rôle à une équipe

Au-dessus de la grille se trouve la liste des équipes de l’environnement, chacune avec une case à cocher. Tous les membres d’une équipe cochée détiennent ce rôle ici, en plus des personnes à qui le rôle a été attribué directement sur la page Utilisateurs. Les deux voies comptent en même temps : une personne membre d’une équipe cochée qui détient aussi le rôle à titre personnel ne le détient qu’une fois.

C’est la seconde moitié de ce que signifie placer quelqu’un dans une équipe. L’appartenance à une équipe décidait déjà quels enregistrements une autorisation atteint — les stratégies de mes équipes — et elle peut désormais décider aussi quelles autorisations ses membres détiennent.

C’est une décision propre à votre organisation : elle ne voyage donc jamais dans une solution. Un package apporte un rôle et ce que ce rôle peut faire ; qui le détient concerne vos collaborateurs, et un éditeur n’a pas son mot à dire. Cette liste est donc la même quelle que soit la solution dans laquelle vous vous trouvez, et une désinstallation n’y touche pas.

Elle prend effet à la requête suivante, comme toute autre modification sur cet écran — y compris lorsque quelqu’un rejoint ou quitte l’équipe par la suite.

Privilèges de plateforme — ce qui ne concerne pas une table

Au-dessus de la grille se trouve une courte liste de cases à cocher : Importer une solution, Exporter une solution, Importer des données. Ce sont les capacités qui n’ont aucune table derrière elles : la seconde question ne s’applique donc pas — il n’y a pas d’enregistrements qu’une stratégie pourrait filtrer. On les détient ou non, et c’est pourquoi ce sont des cases à cocher et non des listes déroulantes.

Ils sont détenus par environnement, comme tout le reste sur cet écran : un rôle qui peut importer une solution dans Dev ne peut pas pour autant en importer une dans Prod.

La gestion des utilisateurs et des rôles ne se trouve pas ici, et c’est délibéré plutôt qu’un oubli. Les utilisateurs et les rôles sont communs à tout le locataire — ils existent quel que soit l’environnement dans lequel vous êtes —, donc « peut gérer les utilisateurs, dans Dev » est une phrase qui ne veut rien dire. Cela reste du ressort de l’administrateur de la plateforme.

La ligne « Toutes les tables » ne couvre pas un privilège. Elle désigne toutes les tables, et la plateforme n’en est pas une. Un privilège s’accorde en le cochant.

Étapes

1. Ouvrez Solutions, puis la solution qui contient votre application.
2. Ouvrez Rôles dans la navigation de la solution.
3. Sélectionnez soit Nouveau pour créer un rôle dont cette solution est propriétaire, soit Ajouter un rôle existant pour accorder un accès à un rôle que votre organisation possède déjà.
4. Dans la grille, réglez chaque cellule sur une stratégie, ou laissez-la sur Non accordé.
5. La première ligne est Toutes les tables. Une attribution faite à cet endroit couvre toutes les tables — y compris celles que vous créerez plus tard, ce que ne ferait pas une attribution table par table.
6. Sélectionnez Enregistrer.

La modification prend effet à la requête suivante. Il n’y a aucun délai à attendre.

Pourquoi cela se fait dans une solution, et pourquoi l’écran ne demande jamais quel environnement

Une autorisation nomme une table, et les tables appartiennent à un environnement ; une attribution qui doit atteindre Test et Prod doit voyager dans un package. Ouvrir une solution a déjà fixé ces deux éléments — une solution appartient à un seul environnement —, si bien que l’écran n’a aucun environnement à vous demander. Pour accorder au même rôle un accès différent ailleurs, exportez la solution et importez-la là-bas, ou changez d’environnement et travaillez dans la solution de cet environnement.

Quels rôles la liste affiche

Un rôle figure dans une solution pour l’une de deux raisons, et les deux apparaissent dans la liste :

• La solution en est propriétaire — il a été créé ici avec Nouveau, et son nom logique porte donc le préfixe de l’éditeur (par_sales).
• La solution lui accorde quelque chose — un rôle que votre organisation possédait déjà, ajouté avec Ajouter un rôle existant.

Ajouter un rôle existant n’écrit rien en soi ; il rejoint la solution dès que vous lui accordez quelque chose et enregistrez. Accorder quelque chose à votre propre rôle sales n’en fait jamais le rôle de l’éditeur : l’appartenance d’un rôle à un package se décide par son préfixe, et une désinstallation ne peut donc pas vous retirer votre rôle.

Retirer de la solution n’efface que les attributions que fait cette solution. Un rôle dont la solution est propriétaire ne peut pas être retiré de cette façon — il appartient au package, et le retirer signifie supprimer le rôle sur la page Rôles du Centre de contrôle d’administration.

La couche que vous modifiez

Les cellules montrent ce qu’accorde cette solution. Lorsqu’une autre couche accorde déjà quelque chose que la solution laisse vide, la cellule l’indique — Déjà accordé ailleurs : … — plutôt que de l’y intégrer. Cette distinction compte, car l’écran réécrit ce qu’il affiche : s’il affichait la réponse fusionnée, un seul enregistrement copierait vos modifications locales, et les attributions des autres solutions, dans votre package.

La solution par défaut (« Main ») fait exception. Ce n’est pas un package : sa grille modifie donc les attributions propres à votre environnement. Elles ne voyagent dans rien, et elles l’emportent sur tout ce qu’accorde une solution. C’est là qu’il faut faire un ajustement local que vous ne voulez pas livrer.

Copier un rôle

Deux rôles qui ne diffèrent que d’une ou deux cellules sont courants — « Ventes » et « Responsable des ventes », « Support » et « Responsable du support » —, et réaccorder le second cellule par cellule, c’est la meilleure façon d’obtenir un rôle de sécurité qui diffère de son jumeau à un endroit que personne n’avait voulu.

1. Ouvrez le rôle qui vous sert de point de départ.
2. Sélectionnez Copier le rôle.
3. Donnez au nouveau rôle un nom d’affichage, celui qu’on lit sur la page Rôles et dans la liste des utilisateurs, par exemple Ventes terrain (lecture seule).
4. Donnez au nouveau rôle un nom logique (préfixé, comme tout autre composant créé par cette solution).
5. Sélectionnez Copier, ajustez les cellules qui doivent différer, puis Enregistrer.

La copie reprend les autorisations telles qu’elles apparaissent à l’écran, y compris les modifications non encore enregistrées — copier un rôle que vous venez d’ajuster doit copier ce que vous avez sous les yeux.

Deux choses qu’elle ne fait délibérément pas :

• Elle ne copie pas le rôle dans les autres environnements. Seulement dans celui-ci. Un même rôle ne signifie pas la même chose dans Dev et dans Prod : copier « ce que ce rôle peut faire » ne peut raisonnablement désigner que ce qu’il peut faire ici.
• Elle ne copie pas les détenteurs du rôle. Ce sont vos collaborateurs, et dupliquer un rôle n’est pas une raison de dupliquer ses membres. Attribuez le nouveau rôle aux personnes qui doivent l’avoir (voir Attribuer un rôle à un utilisateur).

Ce avec quoi démarre un nouvel environnement

Uniquement le rôle Maker, qui reçoit tout sur toutes les tables et les trois privilèges de plateforme. Tous les autres rôles démarrent avec rien — y compris un rôle qu’un utilisateur détient déjà. C’est délibéré : un accès est quelque chose que quelqu’un a accordé, et « rien » est la seule valeur par défaut sur laquelle on peut se tromper sans danger.

L’administrateur du locataire ne figure pas du tout dans la grille. Il a accès à tout par définition et contourne cet écran, de sorte que révoquer la mauvaise chose ne peut jamais vous bloquer l’accès à l’écran qui permettrait de la rétablir.

Quand une solution apporte le rôle

Une solution installée peut apporter des rôles de sécurité avec elle — le rôle et ce qu’il peut faire, car une application livrée sans ses rôles est une application que personne ne peut utiliser. Ces attributions sont déjà en vigueur lorsque l’installation de la solution se termine ; personne n’a besoin de les réaccorder.

Vous pouvez toujours les modifier depuis la solution Main, et votre modification l’emporte :

• Restreignez ou élargissez une cellule et c’est votre réglage qui s’applique, quel que soit celui de la solution.
• Remettez une cellule sur Non accordé et elle reste non accordée — l’attribution de la solution ne revient pas la prochaine fois que vous ouvrez l’écran.
• Mettez à jour la solution et vos modifications sont conservées. Une importation met à jour les attributions propres à la solution et laisse les vôtres intactes.
• Désinstallez la solution et ses attributions partent avec elle. Tout ce que vous avez défini reste ; une cellule que vous aviez modifiée revient à votre valeur, et une cellule que seule la solution accordait devient Non accordé.

Qui détient un rôle ne fait jamais partie d’un package. Ce sont vos collaborateurs, et l’attribution du rôle est toujours faite par quelqu’un d’ici (voir Attribuer un rôle à un utilisateur).

Les stratégies, de la plus restreinte à la plus large

Chacune d’elles peut être choisie, et chacune est appliquée :

Stratégie	Portée
Aucun enregistrement	Rien. Une autorisation accordée ainsi ne fait rien — utile uniquement pour désactiver quelque chose sans supprimer la ligne.
Mes enregistrements	Les enregistrements dont cet utilisateur est personnellement propriétaire.
Les miens et ceux de mes équipes	Ce qui précède, plus les enregistrements dont est propriétaire une équipe à laquelle il appartient.
Enregistrements de mes équipes	Les enregistrements dont est propriétaire une équipe à laquelle il appartient.
Mon unité	Les enregistrements dont le propriétaire se trouve dans sa propre unité organisationnelle.
Mon unité et en dessous	Son unité et toutes les unités situées en dessous.
Mon unité et au-dessus	Son unité et toutes les unités dont elle dépend, jusqu’au sommet.
Toute ma branche	L’unité la plus haute au-dessus de lui, et tout ce qui se trouve en dessous.
Tous les enregistrements	L’environnement entier.

Tout sauf Tous les enregistrements dépend de qui est propriétaire d’un enregistrement et de la place des unités dans l’organisation. Le propriétaire d’un enregistrement est défini à sa création et peut être transmis par la suite (voir Changer le propriétaire d’un enregistrement) ; les unités et les équipes sont des tables de l’environnement : vous y construisez votre organisation, et les stratégies la suivent.

L’unité d’un enregistrement est celle de son propriétaire, fixée à sa création puis à chaque fois qu’il est attribué à quelqu’un d’autre. Changer une personne d’unité ensuite ne déplace pas ce qu’elle possède déjà ; réattribuez ces enregistrements s’ils doivent la suivre. Aucune stratégie d’unité n’atteint les enregistrements d’une personne sans unité.

Une stratégie que le moteur ne sait pas évaluer est listée sous la grille mais ne peut pas être sélectionnée — une attribution que le moteur ne sait pas évaluer afficherait sur cet écran un accès que l’utilisateur n’a pas réellement. Aujourd’hui, toutes les stratégies intégrées sont évaluables : rien n’y apparaît donc.

Ce que voit un utilisateur quand une attribution est restreinte

Un utilisateur ne voit pas les commandes que son rôle n’atteint pas. Sur une table dans laquelle il ne peut pas créer d’enregistrements, il n’y a pas de bouton Nouveau ; sur une table dont il ne peut rien supprimer, pas de Supprimer ; et une table qu’il peut lire mais pas mettre à jour ouvre ses enregistrements en lecture seule, sans Enregistrer. Une attribution restreinte se lit donc comme une application plus simple plutôt que comme un mur de refus — et l’autorisation est tout de même vérifiée par le serveur à chaque fois, quoi que l’écran ait choisi d’afficher.

Dépannage

• « … n’est pas une autorisation que cet environnement peut accorder. » — la table a été supprimée après la rédaction du rôle. Rouvrez l’écran et définissez de nouveau l’attribution.
• « … figure deux fois. » — un rôle détient une autorisation sous une seule stratégie. Définissez la cellule une seule fois.
• Un utilisateur ne voit toujours pas d’enregistrements après que j’ai accordé le rôle. — vérifiez quel rôle porte réellement son jeton ; une attribution à « Sales » ne fait rien pour un utilisateur dont la revendication indique « sales ». Si vous avez attribué le rôle à une équipe, vérifiez qu’il en fait partie — sous Équipes.
• Il n’y a pas de liste d’équipes à l’écran. — l’environnement n’en a encore aucune, ou son modèle d’organisation n’a pas été initialisé. Créez une équipe sous Équipes et rouvrez le rôle.
• J’ai tout retiré et plus personne ne peut utiliser l’application. — c’est bien ce que cela fait. Accordez de nouveau le rôle ; en tant qu’administrateur, votre propre accès n’est pas affecté.
• « Vous ne détenez pas le privilège “…” dans cet environnement. » — la personne tente d’importer une feuille de calcul, ou d’importer ou d’exporter une solution, et son rôle n’a pas la case correspondante cochée. Cochez-la dans Privilèges de plateforme, au-dessus de la grille.
• « … est un privilège de plateforme : il est détenu ou non. » — un privilège a été envoyé avec une stratégie. Rien à l’écran ne peut faire cela ; cela vient d’un package de solution qui en nommait une.
• La grille est vide. — aucun environnement n’est sélectionné en haut de la fenêtre, ou cet environnement n’a encore aucune table.
• Un rôle que j’ai ajouté a disparu de la liste. — vous l’avez enregistré sans rien lui accorder. Un rôle figure dans la solution parce que la solution lui accorde quelque chose ; ajoutez-le de nouveau et accordez-lui quelque chose.
• J’ai accordé le rôle dans Dev et rien n’a changé dans Prod. — c’est normal : les autorisations sont propres à chaque environnement. Exportez la solution et importez-la dans Prod (voir Importer une solution dans un environnement), ce qui est précisément la raison d’être des attributions placées dans une solution.

Scénarios associés

• Écrire une stratégie de données — lorsqu’aucune des stratégies intégrées ne dit ce que vous voulez dire.
• Placer un utilisateur dans une équipe — ce que lisent les stratégies d’équipe.
• Créer un rôle.
• Attribuer un rôle à un utilisateur.