Permisos

Introducción

La pestaña Permissions define, para un repositorio dado, quién puede leer o escribir en qué carpetas. Un permiso apunta a un grupo o un usuario, se aplica a un patrón de ruta y lleva un nivel (write / read / none). El rol dice lo que una cuenta puede hacer; el permiso dice sobre qué archivos.

Acceso y roles

La pestaña está disponible para el super admin (todos los repositorios) y para el project_admin (los repositorios que administra). Las reglas siempre están asociadas al repositorio seleccionado.

Los tres niveles

Conceder un acceso

1. Seleccione el repositorio y luego la pestaña Permissions.
2. Elija el sujeto en el selector: un grupo o un usuario (dos sublistas "Groups" y "Users"). Una regla apunta a uno u otro, nunca a ambos.
3. En el árbol de carpetas, marque las carpetas afectadas (las casillas tienen tres estados: todo / parcial / nada). Un campo de búsqueda filtra el árbol.
4. En la barra que aparece, elija el nivel (write / read / none) y haga clic en Apply.

Las reglas activas del sujeto se muestran en una tabla (patrón, nivel, prioridad) donde puede eliminarlas una a una.

Conceder por nombre de usuario

El botón "+ By username" permite conceder acceso a alguien que no aparece en la lista visible, escribiendo su nombre exacto. Es la manera de conceder acceso a una cuenta fuera de su ámbito habitual, por ejemplo un playtester que aún no tiene ningún permiso.

El nombre debe coincidir exactamente (sin prefijo). El campo solo devuelve el identificador y el nombre, nunca el rol, para que no sirva para sondear las cuentas existentes.

Patrones y prioridad

Una carpeta marcada Foo/Bar se convierte en el patrón Foo/Bar/** (la carpeta y todo lo que contiene, a cualquier profundidad). La raíz del repositorio se convierte en /**.

Cada regla recibe una prioridad automática igual a la profundidad de la carpeta (número de segmentos, raíz = 0). Una regla más específica (más profunda) prevalece por tanto sobre una más general. Ejemplo: write en Content/** y none en Content/Secret/** da acceso de escritura en todo Content/ salvo en Secret/.

Resolución por defecto

Cuando ninguna regla explícita cubre una ruta, el acceso efectivo sigue este modelo:

• Por defecto, el acceso es read (lectura) cuando ninguna regla coincide.
• admin y lead tienen write en todas partes (elusión de rol).
• Un project_admin tiene write en los repositorios que administra y nada especial en otros lugares.
• De lo contrario, se aplica la regla más específica; a falta de ella, la lectura por defecto.

Dicho de otro modo: para prohibir la lectura de una carpeta a alguien, no basta con no conceder nada (el valor por defecto es read), hace falta una regla none explícita.

Probar un permiso

El panel Test Permission responde a "¿qué acceso efectivo tiene este usuario sobre esta ruta?". Elija un usuario, introduzca una ruta (p. ej. /Content/Maps/Level01.umap) y ejecute la prueba. El resultado muestra el nivel efectivo, así como la fuente y el patrón que decidieron, lo que permite entender por qué se concede o se deniega un acceso.

Para un usuario que no tiene derecho a ver, la prueba devuelve el mismo "no encontrado" que una cuenta inexistente, a fin de no revelar la existencia de las cuentas.

Errores comunes

"No concedí nada y sin embargo puede leer"

Es el valor por defecto read. Para cerrar una carpeta, ponga una regla none explícita sobre ella.

Dos reglas se contradicen

Gana la más específica (mayor profundidad). Use la prueba para ver cuál decide.

Un lead sigue en escritura pese a una regla none

Los roles admin y lead eluden las reglas de ruta (write en todas partes). Una regla none no los restringe. Lo mismo para un project_admin en sus propios repositorios.

Acceso por grupo frente a acceso directo

Un acceso puede provenir de la propia cuenta o de un grupo del que es miembro. Si quitar una regla no cambia nada, busque la otra fuente (la prueba indica cuál se aplica).