Permissions

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 niveaux

Accorder un accès

1. Sélectionnez le dépôt, puis l'onglet Permissions.
2. Choisissez le sujet dans le sélecteur : un groupe ou un utilisateur (deux sous-listes « Groups » et « Users »). Une règle vise l'un ou l'autre, jamais les deux.
3. Dans l'arbre de dossiers, cochez les dossiers concernés (les cases sont à trois états : tout / partiel / rien). Un champ de recherche filtre l'arbre.
4. Dans la barre qui apparaît, choisissez le niveau (write / read / none) et cliquez Apply.

Les règles actives du sujet s'affichent dans un tableau (pattern, niveau, priorité) où vous pouvez les supprimer une à une.

Accorder par nom d'utilisateur

Le bouton « + par nom d'utilisateur » 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é

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

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, il ne suffit pas de ne rien accorder (le défaut est read), il faut une règle none explicite.

Tester une permission

Le panneau Test Permission répond à « quel accès effectif a cet utilisateur sur ce chemin ? ». Choisissez un utilisateur, saisissez un chemin (ex. /Content/Maps/Level01.umap) et lancez le 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é.

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. Pour fermer un dossier, posez une règle none explicite dessus.

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