权限

简介

Permissions 选项卡为指定的仓库定义谁可以读取或写入哪些文件夹。 权限的对象是 一个群组或一个用户，适用于某个 路径模式， 并带有一个 级别（write / read / none）。角色说明一个账户能做什么，权限说明 针对哪些文件。

访问与角色

此选项卡对 超级管理员（所有仓库）和 project_admin （其管理的仓库）开放。规则始终附加到所选仓库。

选项卡的三个面板

Permissions 选项卡位于管理面板的 PROJECT 行: 你在这里所做的一切仅对 行首选择器中显示的仓库生效。正上方的 SERVER 行则相反，关乎整个服务器，账户和群组就存放在那里。

此选项卡自上而下叠放着 三个不同的面板。它们回答三个不同的问题，把前两个与文件夹树混淆，是 本页最常见的求助原因。

面板	它回答的问题	谁可以访问
Project Admins	谁管理这个项目？	仅超级管理员
Build Access	谁可以下载这个项目的构建？	超级管理员和 project_admin
权限树	谁可以读取或写入哪些文件夹？	超级管理员和 project_admin

本页余下部分先介绍作为主面板的权限树，再介绍另外两个。

三个级别

级别	效果
write	对所覆盖路径的读取和写入（检出、签入）。
read	只读: 可以同步，不能修改。
none	无访问权限: 即使有更宽泛的规则允许，也会显式隐藏某个文件夹。

授予访问权限

1. 在正确的项目上打开 Permissions 选项卡

PROJECT 行，行首的仓库选择器: 在做任何事之前先核对显示的项目，规则将只附加到它。

2. 选择对象

在选择器中选取一个群组 或 一个用户: 列表分为 Groups 和 Users 两个子列表。一条规则针对其中之一，绝不同时针对两者。只要未选择对象，Apply 按钮就保持禁用。

3. 勾选文件夹

在 文件夹树 中勾选相关文件夹。复选框为三态（全部、部分、无），Filter folders... 字段在项目较大时可缩减树。

4. 选择级别并应用

一旦勾选了文件夹便会出现一个栏: 它会显示所选文件夹的数量，并提供三个级别（write、 read、none）。选一个，然后点击 Apply。对象的规则随即显示在下方的 Active rules 表格（Path Pattern、Permission、Priority）中，你可以 逐条删除。

按用户名授予

"+ By username" 按钮可让你为未出现在可见列表中的人授予访问权限，方法是输入其 准确的名称。这是为通常范围之外的账户授予访问权限的方式，例如尚未持有任何权限的 playtester。

名称必须 完全匹配（不支持前缀）。该字段只返回标识符和名称，绝不返回角色， 以免被用来探测现有账户。

模式与优先级

规则针对的不是某个具体文件，而是一个 路径模式，即所谓的 glob: 一种简写记法， 其中 * 代表名称中任意的字符序列，** 代表任意深度的任意文件夹序列。因此 Content/Maps/** 表示 Content/Maps 之下的一切，包括子文件夹。你无需手写它们: 在树中 勾选一个文件夹即会生成对应的 glob。

勾选的文件夹 Foo/Bar 会成为模式 Foo/Bar/**（该文件夹及其在任意深度包含的 全部内容）。仓库根目录会成为 /**。

每条规则会自动获得一个 等于文件夹深度的优先级（段数，根 = 0）。 因此更 具体（更深）的规则会优先于更一般的规则。 例如: 在 Content/** 上设 write，在 Content/Secret/** 上设 none， 则在 Content/ 中处处可写，唯独 Secret/ 除外。

默认解析

当没有显式规则覆盖某个路径时，有效访问遵循以下模型:

• 默认情况下，当没有规则匹配时，访问为 read（读取）。
• admin 和 lead 处处拥有 write（角色绕过）。
• project_admin 在 其管理的仓库上拥有 write，在其他地方没有特殊权限。
• 否则，应用最具体的规则；若都不匹配，则为默认读取。

换句话说: 要对 已经能访问仓库 的人 禁止 读取某个文件夹，仅仅不授予任何权限是 不够的（默认是 read），需要一条显式的 none 规则。

实际后果，且能省去无用功: 一个没有任何规则的全新项目已经对所有人关闭，除了 admin 和 lead 角色以及它自己的 project_admin。因此不必到处放置 none 规则来「关闭」一个项目； 只需授予你想开放的部分即可。none 规则用于在一个已授予的访问 内部 进行切分，例如对拥有 Content/ 的团队隐藏 Content/Secret/。

指定项目管理员

选项卡顶部的 Project Admins 面板指定谁管理所选仓库。它 仅限超级管理员: 授予 权限比行使权限高一级。

过程分两步，按此顺序:

1. 在 Users 选项卡中赋予角色

SERVER 行，Users 选项卡: 给此人赋予 project_admin 角色。只要未 设置该角色，此人就不会出现在本面板的列表中，面板也会这样提示: 「No one to add. Give someone the Project Admin role on the Users tab first」。

2. 将此人关联到仓库

回到这里，核对 PROJECT 行选择器中显示的仓库，然后在 Project Admins 面板点击 Add， 选择此人并点击 Grant。此人随即出现在面板列表中。

移除关联

行末的红色叉号（Revoke）会将该仓库移出其范围。没有关联的角色 什么都不给: 一个 不再管理任何仓库的 project_admin 会失去对 Permissions、Rules、Webhooks、Files 以及用户管理的访问。因此移除 最后一个仓库确实会连同全部权限一起移除。

构建访问

Build Access 面板决定谁可以从客户端的 Games 页面查看并下载这个项目的 已发布构建。 它向 超级管理员 以及在其仓库上的 project_admin 开放。

1. 打开添加表单

在 Build Access 面板点击 Add。会出现一行输入，首先从选择如何指定目标开始。

2. 指定目标

• User: 列表中的一个账户，也就是已经在该项目上工作的人。
• Group: 整个 群组，便于一届学生或一个经常性的测试团队。
• By username: 一个 Exact username 字段，你在其中输入账户的准确名称。这是 playtester 的常规途径，因为它不出现在任何列表中。名称必须准确匹配，不带前缀。

3. 授予或撤销

点击 Grant 以授予。在已有的一行上，Revoke 会在确认后移除该访问。

服务器按顺序应用的规则:

谁	构建访问
admin	所有仓库。
project_admin	其管理的仓库。
所有其他角色	必须持有 download_builds 能力（除 viewer 外所有角色都 持有），并且 要么能访问该仓库，要么在此面板中有一条记录，无论是直接的还是通过群组。

换句话说: 已经在该项目上工作的人在这里无需任何额外设置。此面板服务于项目 之外 的人，而 viewer 在任何情况下都被排除。

测试权限

选项卡最底部的 Test Permission 面板回答「该用户对此路径拥有什么有效访问权限?」。这是了解你的 哪条规则真正起决定作用的最短途径。

1. 选择用户和路径

在 User 中选取一个账户，然后在 Path 中输入一个路径，例如 /Content/Maps/Level01.umap。只要两者未填写，按钮就保持禁用。

2. 运行测试并阅读结果

点击 Test。结果会显示有效级别，以及做出判定的 来源 和 模式， 从而让你理解为何授予或拒绝访问。

对于你无权查看的用户，测试返回与不存在账户相同的「未找到」，以免泄露账户的存在。

常见陷阱

「我什么都没授予，他却能读取」

这是 read 默认值，它只在 此人已能访问的仓库内部 起作用。要对在项目上工作的人关闭 某个文件夹，请在其上放置一条显式的 none 规则。

「仓库不出现在他的列表中」

只要他对这个仓库 没有 任何 none 以外的规则，这就是正常的。read 默认值 并不给予对仓库本身的访问。直接或通过 群组 给他至少一条 read 或 write 规则，仓库便会出现。如果这是一个只需获取构建的 playtester，那么不该在这里处理: 参见 构建访问。

两条规则相互矛盾

最具体的那条（深度最大）获胜。用 测试 查看是哪一条在决定。

尽管有 none 规则，lead 仍保持可写

admin 和 lead 角色会绕过路径规则（处处 write）。none 规则不会限制它们。project_admin 对其自己的仓库也是如此。

通过群组访问与直接访问

访问可能来自账户本身，也可能来自其所属的 群组。如果 删除一条规则没有任何变化，请查找另一个来源（测试会指明是哪一个在起作用）。