uVersion
Español
Descargar →

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 almacenamiento. 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.

Abrir el panel

El panel de administración abierto, mostrando la lista de pestañas (Usuarios, Grupos, Permisos, Reglas, Webhooks, Distribución, Almacenamiento).

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 navegación. Las cuentas sin rol de administración no ven esta entrada.

Dos roles abren el panel: admin (super administrador) y project_admin (administrador de proyecto). Lo que ven allí no es idéntico: vea la sección siguiente.

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

RolPara qué sirve
adminSuper administrador: acceso total, todo el servidor.
project_adminAdministrador de proyecto: admin completo de sus repositorios, nada en otro lugar.
leadResponsable de equipo: escritura en todos los repositorios y varias capacidades elevadas (aprobación, actividad global, distribución). De hecho, hoy un rol muy potente.
artistColaborador (arte): check-out / check-in de archivos según sus permisos.
programmerColaborador (código): check-out / check-in según sus permisos.
qaControl de calidad: contribuye y participa en las revisiones.
userColaborador genérico.
viewerSolo lectura.
playtesterAcceso solo a las builds publicadas (descarga de juegos). No ve ni el workspace ni los archivos del repositorio.
El rol define el poder, el permiso define el alcance El rol dice lo que una cuenta puede hacer (administrar, contribuir, leer). Los permisos dicen sobre qué carpetas. Un 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 administrador solo puede actuar sobre una cuenta estrictamente por debajo de su propio rango: así que nadie puede autopromoverse, ni modificar a un par, ni degradarse por debajo de su propio rango. Esto es lo que impide, por ejemplo, que un project_admin (rango 40) se convierta en super admin.

Quién accede a qué pestaña

PestañaSuper adminproject_admin
UsuariosGestión completaSolo creación, lista compartimentada
GruposGestión completaLectura de los nombres (para dirigir una concesión)
PermisosSí, en sus repositorios
ReglasSí, en sus repositorios
WebhooksSí, en sus repositorios
DistribuciónNo (reservado a admin y lead)
Almacenamiento & GCSí, en sus repositorios

Siguen siendo estrictamente de super admin: la modificación / restablecimiento / desactivación de un usuario, la gestión de grupos (más allá de la simple lectura), la auditoría, los ajustes del servidor, las estadísticas globales y la licencia.

Capacidades de todo el servidor

Algunas autorizaciones son capacidades vinculadas al rol y válidas en todo el servidor (no tienen dimensión por repositorio). Dos consecuencias prácticas:

  • Un lead, que posee la capacidad manage_rules, tiene acceso a la Distribución en todo el servidor.
  • Un project_admin no 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.