Wiki

Permissions

Accorder à un groupe ou un utilisateur un accès read / write / none sur des dossiers d'un dépôt. Patterns, priorité, résolution par défaut, test de permission.

Introduction

L'onglet Permissions définit, pour un dépôt donné, qui peut lire ou écrire dans quels dossiers. Une permission cible un groupe ou un utilisateur, s'applique à un pattern de chemin, et porte un niveau (write / read / none). Le rôle dit ce qu'un compte peut faire ; la permission dit sur quels fichiers.

Accès et rôles

L'onglet est accessible au super admin (tous les dépôts) et au project_admin (les dépôts qu'il administre). Les règles sont toujours attachées au dépôt sélectionné.

Les trois panneaux de l'onglet

L'onglet Permissions vit dans la rangée PROJECT du panneau d'administration : tout ce que vous y faites ne vaut que pour le dépôt affiché dans le sélecteur, en tête de rangée. La rangée SERVER, juste au-dessus, concerne au contraire le serveur entier, et c'est là que vivent les comptes et les groupes.

L'onglet empile trois panneaux distincts, du haut vers le bas. Ils répondent à trois questions différentes, et confondre les deux premiers avec l'arbre de dossiers est la cause d'appel la plus fréquente sur cette page.

Panneau	Question à laquelle il répond	Qui y a accès
Project Admins	Qui administre ce projet ?	Super admin seulement
Build Access	Qui peut télécharger les builds de ce projet ?	Super admin et project_admin
Arbre des permissions	Qui peut lire ou écrire dans quels dossiers ?	Super admin et project_admin

L onglet Permissions vu depuis le haut, avec ses trois panneaux empiles et remplis : Project Admins qui liste un administrateur de projet, Build Access qui liste un acces accorde, puis le debut de l arbre des permissions. La rangee PROJECT et son selecteur de depot sont visibles au-dessus.

Le reste de cette page décrit d'abord l'arbre des permissions, qui est le panneau principal, puis les deux autres.

Les trois niveaux

Niveau	Effet
`write`	Lecture et écriture (check-out, check-in) sur les chemins couverts.
`read`	Lecture seule : peut synchroniser, pas modifier.
`none`	Aucun accès : masque explicitement un dossier, même si une règle plus large l'autoriserait.

Accorder un accès

1. Ouvrir l'onglet Permissions sur le bon projet

Rangée PROJECT, sélecteur de dépôt en tête de rangée : vérifiez le projet affiché avant toute chose, les règles seront attachées à lui seul.

2. Choisir le sujet

Dans le sélecteur, prenez un groupe ou un utilisateur : la liste est coupée en deux sous-listes, Groups et Users. Une règle vise l'un ou l'autre, jamais les deux. Tant qu'aucun sujet n'est choisi, le bouton Apply reste inactif.

3. Cocher les dossiers

Dans l'arbre de dossiers, cochez ceux qui sont concernés. Les cases sont à trois états (tout, partiel, rien), et le champ Filter folders... réduit l'arbre quand le projet est gros.

4. Choisir le niveau et appliquer

Une barre apparaît dès qu'un dossier est coché : elle annonce le nombre de dossiers sélectionnés et propose les trois niveaux (write, read, none). Choisissez-en un, puis cliquez Apply. Les règles du sujet s'affichent alors en dessous, dans le tableau Active rules (Path Pattern, Permission, Priority), où vous pouvez les supprimer une à une.

L arbre de dossiers avec plusieurs dossiers coches, le selecteur de sujet en haut a gauche, la barre qui annonce le nombre de dossiers selectionnes avec les pastilles write, read et none et le bouton Apply a droite, puis le tableau Active rules et ses colonnes Path Pattern, Permission et Priority.

Accorder par nom d'utilisateur

Le bouton « + By username » permet d'accorder un accès à quelqu'un qui n'apparaît pas dans la liste visible, en tapant son nom exact. C'est le moyen d'accorder un accès à un compte hors de votre périmètre habituel, par exemple un playtester qui ne détient encore aucune permission.

Le nom doit correspondre exactement (pas de préfixe). Le champ ne renvoie que l'identifiant et le nom, jamais le rôle, pour ne pas servir à sonder les comptes existants.

Patterns et priorité

Une règle ne vise pas un fichier précis mais un motif de chemin, ce qu'on appelle un glob : une écriture abrégée où * remplace n'importe quelle suite de caractères dans un nom, et ** n'importe quelle suite de dossiers, à toute profondeur. Ainsi Content/Maps/** désigne tout ce qui se trouve sous Content/Maps, sous-dossiers compris. Vous n'avez pas à les écrire à la main : cocher un dossier dans l'arbre produit le glob correspondant.

Un dossier coché Foo/Bar devient le pattern Foo/Bar/** (le dossier et tout ce qu'il contient, à toute profondeur). La racine du dépôt devient /**.

Chaque règle reçoit une priorité automatique égale à la profondeur du dossier (nombre de segments, racine = 0). Une règle plus spécifique (plus profonde) l'emporte donc sur une règle plus générale. Exemple : write sur Content/** et none sur Content/Secret/** donne un accès en écriture partout dans Content/ sauf dans Secret/.

Regroupement automatique Si vous cochez tous les enfants d'un dossier, le client les regroupe en une seule règle Parent/** (qui couvre aussi les futurs sous-dossiers) et supprime les règles enfant devenues redondantes.

Résolution par défaut

Quand aucune règle explicite ne couvre un chemin, l'accès effectif suit ce modèle :

Par défaut, l'accès est read (lecture) quand aucune règle ne correspond.
admin et lead ont write partout (contournement de rôle).
Un project_admin a write sur les dépôts qu'il administre, et rien de spécial ailleurs.
Sinon, c'est la règle la plus spécifique qui s'applique ; à défaut, la lecture par défaut.

Autrement dit : pour interdire la lecture d'un dossier à quelqu'un qui a déjà accès au dépôt, il ne suffit pas de ne rien accorder (le défaut est read), il faut une règle none explicite.

Le défaut read porte sur les dossiers, pas sur le dépôt Le défaut read répond à « ce chemin-ci, à l'intérieur d'un dépôt auquel la personne a déjà accès ». Il ne rend aucun dépôt public. Un compte qui ne détient aucune règle autre que none sur un dépôt (ni en direct, ni via un groupe) ne voit pas ce dépôt du tout : il n'apparaît ni dans sa liste de dépôts, ni dans son espace de travail, et les routes du serveur le refusent.

Conséquence pratique, et elle évite du travail inutile : un projet neuf sans aucune règle est déjà fermé à tout le monde, sauf aux rôles admin et lead et à ses propres project_admins. Il n'est donc pas nécessaire de poser des règles none partout pour « fermer » un projet ; il suffit de n'accorder que ce que vous voulez ouvrir. Les règles none servent à découper à l'intérieur d'un accès déjà accordé, par exemple pour masquer Content/Secret/ à une équipe qui a Content/.

Nommer un administrateur de projet

Le panneau Project Admins, en haut de l'onglet, désigne qui administre le dépôt sélectionné. Il est réservé au super admin : accorder l'autorité est un cran au-dessus de l'exercer.

La procédure est en deux temps, dans cet ordre :

1. Donner le rôle, dans l'onglet Users

Rangée SERVER, onglet Users : donnez à la personne le rôle project_admin. Tant que ce rôle n'est pas posé, elle n'apparaît pas dans la liste de ce panneau, qui vous le dit d'ailleurs : « No one to add. Give someone the Project Admin role on the Users tab first ».

2. Rattacher la personne au dépôt

Revenez ici, vérifiez le dépôt affiché dans le sélecteur de la rangée PROJECT, puis dans le panneau Project Admins cliquez Add, choisissez la personne et cliquez Grant. Elle apparaît aussitôt dans la liste du panneau.

Le panneau Project Admins en cours d ajout : le menu Select a project admin a cote du bouton Grant, et en dessous une personne deja rattachee, suivie de la mention granted by et de la croix rouge Revoke.

Retirer un rattachement

La croix rouge en bout de ligne (Revoke) retire le dépôt de son périmètre. Le rôle sans le rattachement ne donne rien : un project_admin qui n'administre plus aucun dépôt perd l'accès à Permissions, Rules, Webhooks, Files et à la gestion des utilisateurs. Retirer le dernier dépôt retire donc bien toute l'autorité.

Accès aux builds

Le panneau Build Access décide qui peut voir et télécharger les builds publiés de ce projet depuis la page Games du client. Il est ouvert au super admin et au project_admin sur ses dépôts.

C'est le seul moyen d'ouvrir un projet à un playtester Un compte playtester ne détient, par conception, aucune permission de chemin : c'est ce qui l'empêche de voir les fichiers du projet. Il n'apparaît donc dans aucun arbre de permissions et vous ne pouvez pas lui « donner accès » par l'arbre. Le panneau Build Access existe exactement pour ce cas : il donne accès aux builds sans donner accès aux fichiers.

1. Ouvrir le formulaire d'ajout

Dans le panneau Build Access, cliquez Add. Une ligne de saisie apparaît, qui commence par le choix de la manière de désigner la cible.

2. Désigner la cible

User : un compte de la liste, c'est-à-dire quelqu'un qui travaille déjà sur le projet.
Group : un groupe entier, pratique pour une promotion d'étudiants ou une équipe de test récurrente.
By username : un champ Exact username où vous tapez le nom exact du compte. C'est la voie normale pour un playtester, puisqu'il ne figure dans aucune liste. Le nom doit correspondre exactement, sans préfixe.

Le panneau Build Access en cours d ajout : le menu de type positionne sur By username, le champ Exact username rempli, le bouton Grant a droite, et en dessous une ligne deja accordee avec sa croix rouge de retrait.

3. Accorder, ou retirer

Cliquez Grant pour accorder. Sur une ligne existante, Revoke retire l'accès, avec une confirmation.

La règle appliquée par le serveur, dans l'ordre :

Qui	Accès aux builds
`admin`	Tous les dépôts.
`project_admin`	Les dépôts qu'il administre.
Tous les autres rôles	Il faut détenir la capacité `download_builds` (tous les rôles l'ont sauf `viewer`) et soit avoir accès au dépôt, soit avoir une ligne dans ce panneau, en direct ou via un groupe.

Autrement dit : quelqu'un qui travaille déjà sur le projet n'a besoin de rien de plus ici. Ce panneau sert aux personnes extérieures au projet, et un viewer reste exclu dans tous les cas.

Tester une permission

Le panneau Test Permission, tout en bas de l'onglet, répond à « quel accès effectif a cet utilisateur sur ce chemin ? ». C'est le moyen le plus court de savoir laquelle de vos règles décide vraiment.

1. Choisir l'utilisateur et le chemin

Prenez un compte dans User, puis saisissez un chemin dans Path, par exemple /Content/Maps/Level01.umap. Le bouton reste inactif tant que les deux ne sont pas remplis.

2. Lancer le test et lire le résultat

Cliquez Test. Le résultat affiche le niveau effectif, ainsi que la source et le pattern qui ont décidé, ce qui permet de comprendre pourquoi un accès est accordé ou refusé.

Le panneau Test Permission avec un résultat montrant le niveau effectif, la source et le pattern décisifs.

Pour un utilisateur que vous n'avez pas le droit de voir, le test renvoie le même « introuvable » qu'un compte inexistant, afin de ne pas révéler l'existence des comptes.

Pièges courants

« Je n'ai rien accordé, pourtant il peut lire »

C'est le défaut read, et il ne joue qu'à l'intérieur d'un dépôt auquel la personne a déjà accès. Pour fermer un dossier à quelqu'un qui travaille sur le projet, posez une règle none explicite dessus.

« Le dépôt n'apparaît pas dans sa liste »

C'est normal tant qu'il ne détient aucune règle autre que none sur ce dépôt. Le défaut read ne donne pas accès au dépôt lui-même. Accordez-lui au moins une règle read ou write, en direct ou via un groupe, et le dépôt apparaîtra. S'il s'agit d'un playtester qui doit seulement récupérer les builds, ce n'est pas ici qu'il faut agir : voir Accès aux builds.

Deux règles se contredisent

C'est la plus spécifique (profondeur la plus grande) qui gagne. Utilisez le test pour voir laquelle décide.

Un lead reste en écriture malgré une règle none

Les rôles admin et lead contournent les règles de chemin (write partout). Une règle none ne les restreint pas. Idem pour un project_admin sur ses propres dépôts.

Accès via groupe vs accès direct

Un accès peut venir du compte lui-même ou d'un groupe dont il est membre. Si retirer une règle ne change rien, cherchez l'autre source (le test indique laquelle s'applique).