La matriz de derechos de acceso: una fila por permiso, una columna por rol o grupo
Traducido del English por IA ·
La primera pestaña de Ajustes > Control de acceso, y donde los grupos de mi publicación de octubre se convierten en columnas.
Las filas son los permisos de los módulos que tiene su organización, agrupados por módulo. En la captura es el módulo Diseños 3D con dos permisos, cada uno con una etiqueta, su clave y una descripción. Ver diseños 3D (dashboard_viewer.designs.read) está marcado para Propietario, Administrador y Usuario. Crear, editar y eliminar diseños 3D (dashboard_viewer.designs.write) está marcado para Propietario y Administrador, así que un Usuario aquí abre los diseños solo en lectura.Lea las descripciones, no solo las etiquetas. La de escritura indica que un guardado que añade elementos de una biblioteca 3D que la organización no posee se rechaza sea cual sea el rol, con un 422 viewer_piece_locked.Las columnas son los roles integrados, marcados como integrados, más una por cada uno de sus grupos. Marque o desmarque celdas y el botón de la esquina superior derecha pasa a ser Guardar (n), con el número de cambios. En la captura dice Guardado porque no hay nada pendiente. La columna Propietario y los permisos exclusivos del propietario solo pueden ser modificados por un propietario.El cuadro de filtro busca por nombre, clave, grupo o módulo. Escribir iot_rpc reúne los permisos de comandos, más rápido que ir paginando.Dos cosas que tener en cuenta. Cuando se aplica una política de acceso, su denegación prevalece sobre cualquier marca aquí. Y después de añadir un módulo, revise sus filas: un permiso para el que su organización aún no tiene regla aparece como Permitido por defecto, lo que significa que los miembros pueden usarlo si su rol cumple el mínimo.Para dar a una persona un derecho sin convertirla en Administrador, la matriz suele ser más sencilla que una política: añádala a un grupo y marque el permiso en la columna de ese grupo. Documentación: Grupos y permisos.
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.
Traducido del English por IA ·
Entonces, para nuestro único diseñador, que es User, crearía un grupo y marcaría designs.write para él. ¿O write necesita Admin siempre?
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?
Traducido del English por IA ·
Un grupo funciona. dashboard_viewer.designs.write tiene Admin como rol mínimo, y un grupo puede elevar a un miembro por encima de un mínimo Admin. Solo los mínimos Owner quedan fuera del alcance de los grupos.
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.
Traducido del English por IA ·
La matriz no muestra el rol mínimo de un permiso. ¿Dónde puedo consultarlo?
The matrix doesn’t show the minimum role of a permission. Where do I look that up?
Traducido del English por IA ·
En la referencia de permisos: cada permiso de IoT con su rol mínimo y lo que permite, además de los de la plataforma con los que más se encuentran los administradores de IoT. Los ID que aparecen allí son las claves que ve en la matriz, así que puede pegar uno en el filtro.
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.
Traducido del English por IA ·
Añadí la plantilla del visor IoT el lunes. Aparece aquí en su propia columna, útil para ver exactamente qué permisos de lectura añade por encima de 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.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.

