Wiki

Permisos

Conceder a un grupo o a un usuario acceso read / write / none a carpetas de un repositorio. Patrones, prioridad, resolución por defecto, prueba de 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 paneles de la pestaña

La pestaña Permissions vive en la fila PROJECT del panel de administración: todo lo que haga ahí solo vale para el repositorio mostrado en el selector, al inicio de la fila. La fila SERVER, justo encima, atañe en cambio a todo el servidor, y es ahí donde viven las cuentas y los grupos.

La pestaña apila tres paneles distintos, de arriba abajo. Responden a tres preguntas diferentes, y confundir los dos primeros con el árbol de carpetas es la causa de consulta más frecuente en esta página.

Panel	Pregunta que responde	Quién tiene acceso
Project Admins	¿Quién administra este proyecto?	Solo el super admin
Build Access	¿Quién puede descargar las builds de este proyecto?	Super admin y project_admin
Árbol de permisos	¿Quién puede leer o escribir en qué carpetas?	Super admin y project_admin

La pestaña Permissions vista desde arriba, con sus tres paneles apilados y llenos: Project Admins que lista un administrador de proyecto, Build Access que lista un acceso concedido, y luego el inicio del árbol de permisos. La fila PROJECT y su selector de repositorio se ven encima.

El resto de esta página describe primero el árbol de permisos, que es el panel principal, y luego los otros dos.

Los tres niveles

Nivel	Efecto
`write`	Lectura y escritura (check-out, check-in) en las rutas cubiertas.
`read`	Solo lectura: puede sincronizar, no modificar.
`none`	Sin acceso: oculta explícitamente una carpeta, incluso si una regla más amplia la permitiría.

Conceder un acceso

1. Abrir la pestaña Permissions en el proyecto correcto

Fila PROJECT, selector de repositorio al inicio de la fila: verifique el proyecto mostrado antes que nada, las reglas quedarán asociadas solo a él.

2. Elegir el sujeto

En el selector, tome un grupo o un usuario: la lista está dividida en dos sublistas, Groups y Users. Una regla apunta a uno u otro, nunca a ambos. Mientras no se elija un sujeto, el botón Apply permanece inactivo.

3. Marcar las carpetas

En el árbol de carpetas, marque las que correspondan. Las casillas tienen tres estados (todo, parcial, nada), y el campo Filter folders... reduce el árbol cuando el proyecto es grande.

4. Elegir el nivel y aplicar

Aparece una barra en cuanto se marca una carpeta: indica el número de carpetas seleccionadas y ofrece los tres niveles (write, read, none). Elija uno y luego haga clic en Apply. Las reglas del sujeto se muestran entonces debajo, en la tabla Active rules (Path Pattern, Permission, Priority), donde puede eliminarlas una a una.

El árbol de carpetas con varias carpetas marcadas, el selector de sujeto arriba a la izquierda, la barra que indica el número de carpetas seleccionadas con las píldoras write, read y none y el botón Apply a la derecha, y luego la tabla Active rules y sus columnas Path Pattern, Permission y Priority.

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 regla no apunta a un archivo concreto sino a un patrón de ruta, lo que se llama un glob: una notación abreviada donde * reemplaza cualquier secuencia de caracteres en un nombre, y ** cualquier secuencia de carpetas, a cualquier profundidad. Así, Content/Maps/** designa todo lo que se encuentra bajo Content/Maps, subcarpetas incluidas. No tiene que escribirlos a mano: marcar una carpeta en el árbol produce el glob correspondiente.

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

Agrupación automática Si marca todos los hijos de una carpeta, el cliente los agrupa en una única regla Parent/** (que también cubre las subcarpetas futuras) y elimina las reglas hijas que han quedado redundantes.

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 que ya tiene acceso al repositorio, no basta con no conceder nada (el valor por defecto es read), hace falta una regla none explícita.

El read por defecto afecta a las carpetas, no al repositorio El read por defecto responde a "esta ruta, dentro de un repositorio al que la persona ya tiene acceso". No hace público ningún repositorio. Una cuenta que no tiene ninguna regla salvo none sobre un repositorio (ni directamente ni a través de un grupo) no ve ese repositorio en absoluto: no aparece ni en su lista de repositorios, ni en su espacio de trabajo, y las rutas del servidor lo rechazan.

Consecuencia práctica, y evita trabajo inútil: un proyecto nuevo sin ninguna regla ya está cerrado a todo el mundo, salvo a los roles admin y lead y a sus propios project_admins. Por tanto no es necesario poner reglas none por todas partes para "cerrar" un proyecto; basta con conceder solo lo que quiere abrir. Las reglas none sirven para recortar dentro de un acceso ya concedido, por ejemplo para ocultar Content/Secret/ a un equipo que tiene Content/.

Nombrar un administrador de proyecto

El panel Project Admins, en la parte superior de la pestaña, designa quién administra el repositorio seleccionado. Está reservado al super admin: conceder la autoridad está un escalón por encima de ejercerla.

El procedimiento consta de dos pasos, en este orden:

1. Dar el rol, en la pestaña Users

Fila SERVER, pestaña Users: dé a la persona el rol project_admin. Mientras no se le asigne ese rol, no aparece en la lista de este panel, que además se lo indica: "No one to add. Give someone the Project Admin role on the Users tab first".

2. Vincular la persona al repositorio

Vuelva aquí, verifique el repositorio mostrado en el selector de la fila PROJECT, y luego en el panel Project Admins haga clic en Add, elija la persona y haga clic en Grant. Aparece de inmediato en la lista del panel.

El panel Project Admins durante una adición: el menú Select a project admin junto al botón Grant, y debajo una persona ya vinculada, seguida de la mención granted by y la cruz roja Revoke.

Quitar una vinculación

La cruz roja al final de la línea (Revoke) quita el repositorio de su ámbito. El rol sin la vinculación no da nada: un project_admin que ya no administra ningún repositorio pierde el acceso a Permissions, Rules, Webhooks, Files y a la gestión de usuarios. Quitar el último repositorio quita, por tanto, toda la autoridad.

Acceso a las builds

El panel Build Access decide quién puede ver y descargar las builds publicadas de este proyecto desde la página Games del cliente. Está abierto al super admin y al project_admin en sus repositorios.

Es la única manera de abrir un proyecto a un playtester Una cuenta playtester no tiene, por diseño, ningún permiso de ruta: es lo que le impide ver los archivos del proyecto. Por eso no aparece en ningún árbol de permisos y no puede "darle acceso" mediante el árbol. El panel Build Access existe exactamente para este caso: da acceso a las builds sin dar acceso a los archivos.

1. Abrir el formulario de adición

En el panel Build Access, haga clic en Add. Aparece una línea de entrada, que empieza por la elección de cómo designar el destinatario.

2. Designar el destinatario

User: una cuenta de la lista, es decir, alguien que ya trabaja en el proyecto.
Group: un grupo entero, práctico para una promoción de estudiantes o un equipo de prueba recurrente.
By username: un campo Exact username donde escribe el nombre exacto de la cuenta. Es la vía normal para un playtester, ya que no figura en ninguna lista. El nombre debe coincidir exactamente, sin prefijo.

El panel Build Access durante una adición: el menú de tipo puesto en By username, el campo Exact username relleno, el botón Grant a la derecha, y debajo una línea ya concedida con su cruz roja de retirada.

3. Conceder o retirar

Haga clic en Grant para conceder. En una línea existente, Revoke retira el acceso, con una confirmación.

La regla aplicada por el servidor, por orden:

Quién	Acceso a las builds
`admin`	Todos los repositorios.
`project_admin`	Los repositorios que administra.
Todos los demás roles	Hay que tener la capacidad `download_builds` (todos los roles la tienen salvo `viewer`) y o bien tener acceso al repositorio, o bien tener una línea en este panel, directamente o a través de un grupo.

Dicho de otro modo: quien ya trabaja en el proyecto no necesita nada más aquí. Este panel sirve a las personas externas al proyecto, y un viewer queda excluido en todos los casos.

Probar un permiso

El panel Test Permission, al final de la pestaña, responde a "¿qué acceso efectivo tiene este usuario sobre esta ruta?". Es la forma más corta de saber cuál de sus reglas decide realmente.

1. Elegir el usuario y la ruta

Tome una cuenta en User, luego introduzca una ruta en Path, por ejemplo /Content/Maps/Level01.umap. El botón permanece inactivo mientras no se rellenen ambos.

2. Ejecutar la prueba y leer el resultado

Haga clic en Test. 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.

El panel Test Permission con un resultado que muestra el nivel efectivo, y la fuente y el patrón decisivos.

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, y solo actúa dentro de un repositorio al que la persona ya tiene acceso. Para cerrar una carpeta a alguien que trabaja en el proyecto, ponga una regla none explícita sobre ella.

"El repositorio no aparece en su lista"

Es normal mientras no tenga ninguna regla salvo none sobre este repositorio. El valor por defecto read no da acceso al repositorio en sí. Concédale al menos una regla read o write, directamente o a través de un grupo, y el repositorio aparecerá. Si se trata de un playtester que solo debe recuperar las builds, no es aquí donde hay que actuar: vea Acceso a las builds.

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