Wiki

Permissions

Grant a group or a user read / write / none access on folders of a repository. Patterns, priority, default resolution, permission testing.

Introduction

The Permissions tab defines, for a given repository, who can read or write in which folders. A permission targets a group or a user, applies to a path pattern, and carries a level (write / read / none). The role says what an account can do; the permission says on which files.

Access and roles

The tab is available to the super admin (all repositories) and to the project_admin (the repositories they administer). Rules are always attached to the selected repository.

The tab's three panels

The Permissions tab lives in the PROJECT row of the administration panel: everything you do there applies only to the repository shown in the selector, at the top of the row. The SERVER row, just above, concerns the whole server instead, and that is where accounts and groups live.

The tab stacks three distinct panels, from top to bottom. They answer three different questions, and confusing the first two with the folder tree is the most frequent source of support calls on this page.

Panel	Question it answers	Who has access
Project Admins	Who administers this project?	Super admin only
Build Access	Who can download this project's builds?	Super admin and project_admin
Permissions tree	Who can read or write in which folders?	Super admin and project_admin

The Permissions tab seen from the top, with its three panels stacked and filled: Project Admins listing a project administrator, Build Access listing a granted access, then the start of the permissions tree. The PROJECT row and its repository selector are visible above.

The rest of this page describes the permissions tree first, which is the main panel, then the other two.

The three levels

Level	Effect
`write`	Read and write (check-out, check-in) on the covered paths.
`read`	Read only: can synchronize, cannot modify.
`none`	No access: explicitly hides a folder, even if a broader rule would allow it.

Granting access

1. Open the Permissions tab on the right project

PROJECT row, repository selector at the top of the row: check the project shown before anything else, the rules will be attached to it alone.

2. Choose the subject

In the picker, take a group or a user: the list is split into two sub-lists, Groups and Users. A rule targets one or the other, never both. As long as no subject is chosen, the Apply button stays inactive.

3. Check the folders

In the folder tree, check the ones concerned. The boxes are three-state (all, partial, none), and the Filter folders... field trims the tree when the project is large.

4. Choose the level and apply

A bar appears as soon as a folder is checked: it announces the number of selected folders and offers the three levels (write, read, none). Choose one, then click Apply. The subject's rules then appear below, in the Active rules table (Path Pattern, Permission, Priority), where you can delete them one by one.

The folder tree with several folders checked, the subject selector at the top left, the bar announcing the number of selected folders with the write, read and none pills and the Apply button on the right, then the Active rules table and its Path Pattern, Permission and Priority columns.

Grant by username

The "+ By username" button lets you grant access to someone who does not appear in the visible list, by typing their exact name. This is the way to grant access to an account outside your usual scope, for example a playtester who does not yet hold any permission.

The name must match exactly (no prefix). The field returns only the identifier and the name, never the role, so it cannot be used to probe existing accounts.

Patterns and priority

A rule does not target a specific file but a path pattern, what is called a glob: a shorthand notation where * stands for any sequence of characters in a name, and ** for any sequence of folders, at any depth. Thus Content/Maps/** designates everything under Content/Maps, sub-folders included. You do not have to write them by hand: checking a folder in the tree produces the corresponding glob.

A checked folder Foo/Bar becomes the pattern Foo/Bar/** (the folder and everything it contains, at any depth). The repository root becomes /**.

Each rule receives an automatic priority equal to the depth of the folder (number of segments, root = 0). A more specific rule (deeper) therefore wins over a more general one. Example: write on Content/** and none on Content/Secret/** gives write access everywhere in Content/ except in Secret/.

Automatic grouping If you check all the children of a folder, the client groups them into a single rule Parent/** (which also covers future sub-folders) and removes the child rules that have become redundant.

Default resolution

When no explicit rule covers a path, the effective access follows this model:

By default, access is read when no rule matches.
admin and lead have write everywhere (role bypass).
A project_admin has write on the repositories they administer, and nothing special elsewhere.
Otherwise, the most specific rule applies; failing that, the default read.

In other words: to deny read on a folder to someone who already has access to the repository, granting nothing is not enough (the default is read), you need an explicit none rule.

The default read applies to folders, not to the repository The default read answers "this path, inside a repository the person already has access to". It makes no repository public. An account that holds no rule other than none on a repository (neither directly nor through a group) does not see that repository at all: it appears neither in its repository list nor in its workspace, and the server routes refuse it.

Practical consequence, and it saves needless work: a brand-new project with no rule at all is already closed to everyone, except the admin and lead roles and its own project_admins. It is therefore not necessary to place none rules everywhere to "close" a project; it is enough to grant only what you want to open. none rules serve to carve out inside an access already granted, for example to hide Content/Secret/ from a team that has Content/.

Naming a project administrator

The Project Admins panel, at the top of the tab, designates who administers the selected repository. It is reserved for the super admin: granting authority is one notch above exercising it.

The procedure has two steps, in this order:

1. Give the role, in the Users tab

SERVER row, Users tab: give the person the project_admin role. As long as that role is not set, they do not appear in this panel's list, which even tells you so: "No one to add. Give someone the Project Admin role on the Users tab first".

2. Attach the person to the repository

Come back here, check the repository shown in the PROJECT row selector, then in the Project Admins panel click Add, choose the person and click Grant. They appear at once in the panel's list.

The Project Admins panel in the middle of an add: the Select a project admin menu next to the Grant button, and below it a person already attached, followed by the granted by note and the red Revoke cross.

Removing an attachment

The red cross at the end of the row (Revoke) removes the repository from their scope. The role without the attachment gives nothing: a project_admin who no longer administers any repository loses access to Permissions, Rules, Webhooks, Files and to user management. Removing the last repository therefore does remove all the authority.

Build access

The Build Access panel decides who can see and download this project's published builds from the client's Games page. It is open to the super admin and to the project_admin on its repositories.

It is the only way to open a project to a playtester A playtester account holds, by design, no path permission: that is what prevents it from seeing the project's files. It therefore appears in no permissions tree and you cannot "give it access" through the tree. The Build Access panel exists exactly for this case: it gives access to the builds without giving access to the files.

1. Open the add form

In the Build Access panel, click Add. An entry row appears, which starts with the choice of how to designate the target.

2. Designate the target

User: an account from the list, that is, someone who already works on the project.
Group: a whole group, handy for a student cohort or a recurring test team.
By username: an Exact username field where you type the account's exact name. This is the normal path for a playtester, since they figure in no list. The name must match exactly, without a prefix.

The Build Access panel in the middle of an add: the type menu set to By username, the Exact username field filled in, the Grant button on the right, and below it a row already granted with its red removal cross.

3. Grant, or revoke

Click Grant to grant. On an existing row, Revoke removes the access, with a confirmation.

The rule applied by the server, in order:

Who	Build access
`admin`	All repositories.
`project_admin`	The repositories they administer.
All other roles	Must hold the `download_builds` capability (all roles have it except `viewer`) and either have access to the repository, or have a row in this panel, directly or through a group.

In other words: someone who already works on the project needs nothing more here. This panel serves people outside the project, and a viewer stays excluded in every case.

Testing a permission

The Test Permission panel, at the very bottom of the tab, answers "what effective access does this user have on this path?". It is the shortest way to know which of your rules really decides.

1. Choose the user and the path

Take an account in User, then enter a path in Path, for example /Content/Maps/Level01.umap. The button stays inactive as long as both are not filled in.

2. Run the test and read the result

Click Test. The result shows the effective level, as well as the source and the pattern that decided, which lets you understand why an access is granted or denied.

The Test Permission panel with a result showing the effective level, the deciding source and pattern.

For a user you are not allowed to see, the test returns the same "not found" as a nonexistent account, so as not to reveal the existence of accounts.

Common pitfalls

"I granted nothing, yet they can read"

That is the read default, and it plays only inside a repository the person already has access to. To close a folder to someone who works on the project, place an explicit none rule on it.

"The repository does not appear in their list"

That is normal as long as they hold no rule other than none on this repository. The read default does not give access to the repository itself. Grant them at least one read or write rule, directly or through a group, and the repository will appear. If it is a playtester who only needs to fetch the builds, this is not where to act: see Build access.

Two rules contradict each other

The most specific one (greatest depth) wins. Use the test to see which one decides.

A lead stays in write despite a none rule

The admin and lead roles bypass path rules (write everywhere). A none rule does not restrict them. Same for a project_admin on their own repositories.

Access via group vs direct access

Access can come from the account itself or from a group it belongs to. If removing a rule changes nothing, look for the other source (the test indicates which one applies).