La matrice des droits d'accès : une ligne par permission, une colonne par rôle ou groupe
Traduit de English par IA ·
Le premier onglet de Paramètres > Contrôle d’accès, et là où les groupes de mon billet d’octobre deviennent des colonnes.
Les lignes sont les permissions des modules de votre organisation, regroupées par module. Sur la capture, il s’agit du module Conceptions 3D avec deux permissions, chacune avec un libellé, sa clé et une description. Consulter les conceptions 3D (dashboard_viewer.designs.read) est coché pour Propriétaire, Administrateur et Utilisateur. Créer, modifier et supprimer des conceptions 3D (dashboard_viewer.designs.write) est coché pour Propriétaire et Administrateur, donc un Utilisateur ouvre ici les conceptions en lecture seule.Lisez les descriptions, pas seulement les libellés. Celle de l’écriture indique qu’un enregistrement qui ajoute des éléments d’une bibliothèque 3D que l’organisation ne possède pas est refusé quel que soit le rôle, avec un 422 viewer_piece_locked.Les colonnes sont les rôles intégrés, marqués comme intégrés, plus une colonne pour chacun de vos groupes. Cochez ou décochez des cellules et le bouton en haut à droite devient Enregistrer (n), avec le nombre de modifications. Sur la capture, il affiche Enregistré car rien n’est en attente. La colonne Propriétaire et les permissions réservées au propriétaire ne peuvent être modifiées que par un propriétaire.La zone de filtre recherche par nom, clé, groupe ou module. Saisir iot_rpc affiche ensemble les permissions de commande, plus rapidement que de parcourir les pages.Deux points à garder en tête. Lorsqu’une politique d’accès s’applique, son refus l’emporte sur toute case cochée ici. Et après avoir ajouté un module, parcourez ses lignes : une permission pour laquelle votre organisation n’a pas encore de règle s’affiche comme Autorisé par défaut, ce qui signifie que les membres peuvent l’utiliser si leur rôle atteint le minimum requis.Pour accorder un droit à une personne sans en faire un Administrateur, la matrice est généralement plus simple qu’une politique : ajoutez-la à un groupe et cochez la permission dans la colonne de ce groupe. Documentation : Groupes et permissions.
The first tab of Settings > Access Control, and where the groups from my October post turn into columns.
Rows are the permissions of the modules your organisation has, grouped by module. In the screenshot it’s the 3D Designs module with two permissions, each with a label, its key and a description. View 3D designs (dashboard_viewer.designs.read) is ticked for Owner, Admin and User. Create, edit and delete 3D designs (dashboard_viewer.designs.write) is ticked for Owner and Admin, so a User here opens designs read-only.
Read the descriptions, not only the labels. The write one tells you that a save which adds items of a 3D library the organisation doesn’t hold is refused whatever the role, with a 422 viewer_piece_locked.
Columns are the built-in roles, marked built-in, plus one for each of your groups. Tick or untick cells and the button at the top right becomes Save (n), with the number of changes. In the shot it reads Saved because nothing is pending. The Owner column and owner-only permissions can only be changed by an owner.
The filter box searches by name, key, group or module. Typing iot_rpc brings up the command permissions together, quicker than paging through.
Two things to keep in mind. Where an access policy applies, its deny wins over any tick here. And after you add a module, go through its rows: a permission your organisation has no rule for yet shows as Allowed by default, which means members can use it if their role meets its minimum.
To give one person a right without making them Admin, the matrix is usually simpler than a policy: put them in a group and tick the permission in that group’s column. Docs: Groups and permissions.
Traduit de English par IA ·
Donc pour notre seul designer qui est User, je créerais un groupe et cocherais designs.write pour lui ? Ou est-ce que write nécessite Admin dans tous les cas ?
So for our one designer who is a User, I’d make a group and tick designs.write for it? Or does write need Admin no matter what?
Traduit de English par IA ·
Un groupe fonctionne. dashboard_viewer.designs.write a Admin comme rôle minimum, et un groupe peut élever un membre au-dessus d’un minimum Admin. Seuls les minimums Owner sont hors de portée pour les groupes.
A group works. dashboard_viewer.designs.write has Admin as its minimum role, and a group can lift a member over an Admin minimum. Only Owner minimums are out of reach for groups.
Traduit de English par IA ·
La matrice n’indique pas le rôle minimum d’une permission. Où puis-je consulter cette information ?
The matrix doesn’t show the minimum role of a permission. Where do I look that up?
Traduit de English par IA ·
Dans la référence des permissions : chaque permission IoT avec son rôle minimum et ce qu’elle autorise, ainsi que les permissions de la plateforme que rencontrent le plus souvent les administrateurs IoT. Les identifiants qui y figurent sont les clés que vous voyez dans la matrice, vous pouvez donc en coller un dans le filtre.
In the Permissions reference: every IoT permission with its minimum role and what it allows, plus the platform ones IoT admins meet most. The ids there are the keys you see in the matrix, so you can paste one into the filter.
Traduit de English par IA ·
J’ai ajouté le modèle de visualisation IoT lundi. Il apparaît ici dans sa propre colonne, pratique pour voir exactement quels droits de lecture il ajoute par rapport à User.
Added the IoT viewer template on Monday. It shows up as its own column here, handy to see exactly which reads it adds on top of User.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.

