Wiki
Roles y panel de administración
El panel de administración de uVersion: quién puede abrirlo, los 9 roles, super admin frente a project_admin, la jerarquía de rangos y qué pestaña está disponible para quién.
Introducción
El panel de administración está integrado en el cliente de escritorio de uVersion. Reúne la gestión de usuarios, grupos, permisos, reglas de validación, webhooks, distribución y los archivos de un repositorio. Esta página explica el sistema de roles en el que se apoya todo lo demás: léala antes que las otras páginas de esta sección.
Tres palabras aparecen por todas partes. Un repositorio es un proyecto versionado en el servidor.
Un rol es la etiqueta que lleva una cuenta (admin, artist,
viewer…) y dice lo que esa cuenta tiene derecho a hacer. Un permiso dice sobre qué
carpetas puede hacerlo.
Abrir el panel
1. Abrir la entrada Admin
Inicie sesión en el cliente de escritorio con una cuenta que tenga un rol de administración y abra la entrada
Admin en la barra lateral. Las cuentas sin rol de administración no ven esta entrada. Dos roles la
abren: admin (super administrador) y project_admin (administrador de proyecto). Lo que ven
allí no es idéntico: vea la sección siguiente.
2. Identificar las dos filas de pestañas
Bajo el título Admin Panel, las pestañas se disponen en dos filas. La de arriba, SERVER, afecta a todo el servidor y no depende de ningún proyecto. La de abajo, PROJECT, actúa sobre el repositorio elegido en el selector de repositorio situado al inicio de esa fila: cambiar de repositorio cambia lo que muestran estas pestañas. Es lo primero que hay que comprobar cuando una pestaña no muestra lo que espera.
Super admin vs project_admin
uVersion distingue dos niveles de administración:
- Super admin (rol
admin): autoridad sobre todo el servidor. Gestiona todos los repositorios, todos los usuarios, los ajustes globales, la auditoría, la licencia. - project_admin: administrador completo, pero solo de los proyectos que administra. En sus repositorios hace todo lo que hace un admin (permisos, reglas, webhooks, GC, obliteración). Fuera de sus repositorios no tiene ningún poder de administración.
El principio: un project_admin es un administrador de pleno derecho de sus propios proyectos, y nada en otro lugar. Por eso su panel está compartimentado: algunas acciones globales (véase más abajo) siguen reservadas al super admin.
Los 9 roles
| Rol | Para qué sirve |
|---|---|
admin | Super administrador: acceso total, todo el servidor. |
project_admin | Administrador de proyecto: admin completo de sus repositorios, nada en otro lugar. |
lead | Responsable de equipo: escritura en todos los repositorios y varias capacidades elevadas (aprobación, actividad global, distribución). De hecho, hoy un rol muy potente. |
artist | Colaborador (arte): check-out / check-in de archivos según sus permisos. |
programmer | Colaborador (código): check-out / check-in según sus permisos. |
qa | Control de calidad: contribuye y participa en las revisiones. |
user | Colaborador genérico. |
viewer | Solo lectura. |
playtester | Acceso solo a las builds publicadas (descarga de juegos). No ve ni el workspace ni los archivos del repositorio. |
artist solo puede modificar las rutas donde se le concedió la escritura.
Rangos y guarda
Los roles se ordenan por rango: admin 100, lead 50, project_admin 40,
programmer / artist / qa / user 10,
viewer / playtester 5.
Un project_admin solo puede asignar un rol estrictamente por debajo de su propio
rango: así que no puede ni autopromoverse, ni degradarse, ni crear o promover un admin, un
lead u otro project_admin.
admin, y actuar sobre otro super admin (modificarlo o eliminarlo). Es necesario, de lo
contrario un segundo super admin creado por error sería imposible de quitar.
Quién accede a qué pestaña
Las pestañas de la fila SERVER valen para todo el servidor. Las de la fila PROJECT actúan sobre el repositorio elegido en el selector, al inicio de esa misma fila.
| Pestaña | Fila | Super admin | project_admin |
|---|---|---|---|
| Dashboard | SERVER | Sí | No |
| Repositories | SERVER | Sí | No |
| Users | SERVER | Gestión completa | Crear y modificar (email, rol); ve todas las cuentas salvo los super admins |
| Groups | SERVER | Gestión completa | No (los grupos siguen siendo seleccionables desde Permissions) |
| Locks | SERVER | Todos los bloqueos del servidor | Sí, limitado a sus repositorios |
| Audit Log | SERVER | Sí | No |
| Distribution | SERVER | Sí | No (reservado a admin y lead) |
| Permissions | PROJECT | Sí | Sí, en sus repositorios |
| Rules | PROJECT | Sí | Sí, en sus repositorios |
| Webhooks | PROJECT | Sí | Sí, en sus repositorios |
| Files | PROJECT | Sí | Sí, en sus repositorios |
Siguen siendo estrictamente de super admin: el restablecimiento de la contraseña de un usuario, su eliminación y el conmutador Activo / Inactivo, la gestión de grupos, la auditoría, el panel de control y la lista de repositorios, la distribución, los ajustes del servidor, las estadísticas globales y la licencia. En cambio, un project_admin puede crear una cuenta y modificar el email y el rol de las cuentas que no son super admin: vea Usuarios.
Capacidades de todo el servidor
Una capacidad es una autorización con nombre (por ejemplo «publicar builds», «aprobar cambios») vinculada a un rol en lugar de a una persona o a una carpeta. Punto importante: una capacidad vale en todo el servidor, no tiene dimensión por repositorio. Dos consecuencias prácticas:
- Un
lead, que posee la capacidadmanage_rules, tiene acceso a la Distribución en todo el servidor. - Un
project_adminno posee ninguna capacidad: su autoridad proviene de la lista de proyectos que administra, no de una capacidad. Es deliberado, una capacidad no puede limitarse a un proyecto.