权限
权限是一系列预定义的功能和操作，分配给获得授权的用户，用于访问某些工作流和文档以及配置管理任务。分配的权限集决定了每个用户对可用功能的访问权限。未被授予权限的用户无法完成相应的任务。
所有配置管理任务以及某些工作流和文档任务需要有特定的预定义权限，为特定的承担者、组和用户提供允许或拒绝权限。未被授予权限的承担者无法完成相应的任务。例如，检出已锁定的文件需要 FetchRevision 和 Lock 权限。
还有一点非常重要，您用来管理 ACL 的应用程序本身也拥有一个 ACL，用于控制何人有权对安全权限进行更新。授权管理 ACL 独立于用于配置管理的 ACL。您还可以根据需要为其他 ACL 创建控制 ACL。
默认情况下，所有权限对被称为 everyone 的承担者组的初始状态为已启用。
权限继承
在本访问控制系统中，权限 (默认) 继承自其父项 ACL，无论是 mks:aa:mks 管理 ACL、产品级别 ACL (mks:im、mks:si)，还是配置管理专用的 ACL (例如项目、子项目或成员 ACL)。
从命名空间结构的存档 ACL 级别向上到顶层 (全局)，PTC RV&S 服务器向 ACL 数据库查询用户访问权限，从而确定用户是否具有执行所请求操作需要的权限。
当用户执行操作时，PTC RV&S 服务器会检查 ACL，确认发起请求的用户或指定的命令是否具有相应权限。ACL 中的权限检查涉及到两个区域：
• 承担者类型 (用户或组)
• 范围 (存档、项目或全局)
当 PTC RV&S 服务器检查权限时，它首先会尝试为目标用户查找最具体的 ACL，然后再搜索更宽泛的 ACL。下图显示了 PTC RV&S 服务器在检查权限时采取的路径。
最具体的权限类型是将承担者定义为用户的存档 ACL (图中的第 1 部分)。之后，服务器会转到所有将承担者定义为组的存档 ACL (图中的第 2 部分)。然后，服务器会检查所有将承担者定义为用户的项目权限 (第 3 部分)，依次类推。
权限状态
权限始终为以下三种状态之一：
• Allowed
允许承担者执行所请求的操作。
• Denied
不允许承担者执行所请求的操作。
• Cleared
实际上是未设置的权限，视为拒绝承担者执行操作。即使权限为 Cleared (已清除)，仍可以通过另一个承担者或父项 ACL 明确允许该权限。
服务器始终使用其在 ACL 层次结构中找到的最具体的权限。例如，与已清除的权限相比，已允许和已拒绝的权限更为具体。
务必注意清除权限和拒绝权限之间的区别。根据继承规则，优先使用明确拒绝的权限，即便已通过另一个承担者允许该权限，亦是如此。但清除某个权限后，仍然可以通过另一个承担者或者父项 ACL 明确允许该权限。
执行 ACL 检查时，PTC RV&S 服务器会在每个级别搜索是否存在已允许或已拒绝的权限。一旦找到，服务器就会停止检查权限。如果是已允许权限，服务器会根据用户的请求执行操作。如果是已拒绝的权限，服务器则发送相应的错误消息。
您还可以在配置 ACL 时选择清除权限。如果您未明确设置操作的权限，则 PTC RV&S 服务器会认为该权限已被清除 (或未指定)。这样允许您在不同级别定义权限。
• 示例
您可以在全局范围内允许您的组拥有 CheckIn 权限，然后为特定项目拒绝某个组的 CheckIn 权限。这种方式使您能够开放允许的权限结构，只在某些级别上限制权限。同样，您也可以反过来在全局级别限制使用权限，然后仅在需要的级别上进行授权。
如果 PTC RV&S 服务器在同一级别发现同时存在已允许和已拒绝的权限，则已拒绝的权限优先。例如，一个用户是两个组的成员，这两个组均列在一个项目 ACL 中。当 PTC RV&S Server 在项目级别检查组承担者时，它发现其中一个组为允许执行操作，而另一个组被拒绝。在这种情况下，由于已拒绝的权限优先，因此该用户被拒绝执行此操作。
开发路径权限
使用“继承权限”功能，您还可以启用或禁用单个开发路径 ACL 的权限继承。单个开发路径 ACL 上的设置会覆盖所选开发路径的全局“开发路径继承”设置。
如果您选择一个开发路径 ACL，并将“继承权限”设置为 true，则目标开发路径 ACL 会从项目 ACL 继承其权限。如果设置为 false，则所选开发路径会从顶层 mks:si ACL 继承其权限。有关创建开发路径 ACL 的详细步骤，请参阅“开发路径权限”。
将“继承权限” 设置为 true 或将全局“开发路径继承” 设置为 true 时，权限继承自树中的主项目。如果主项目中未设置 ACL，则权限解析为顶层 mks:si ACL。因此，如果未设置项目 ACL，并且权限继承设置为 true，则权限解析为顶层 mks:si ACL。
将“继承权限” 设置为 false 时，权限继承自顶层 mks:si ACL。
有关设置开发路径权限继承的详细信息，请参阅“开发路径权限”。
权限冲突的解决
有时用户可能会被标识为拥有自身权限的承担者，同时又属于被授权的组的一部分，在这种情况下，必须了解如何解决权限冲突。
每个 ACL 条目都指定了允许 (如为正) 或拒绝 (如为负) 的权限集。一个承担者最多可以有一个正 ACL 条目和一个负 ACL 条目。即，任何承担者都不允许对同一权限有多个正的或负的 ACL 条目。所有已定义的权限都优先于继承的权限。
在解决 ACL 权限冲突时，任何时候为用户承担者明确指定的权限都优于其所属组的权限。个人权限始终覆盖个人所属组的权限。因此，个人的负权限 (具体的权限拒绝) 会覆盖组的正权限，而个人的正权限会覆盖组的负权限。例如，用户 Patrick Molinas 作为 pmolinas 的用户承担者被允许拥有 CreateProject 权限，但又作为 Developers 的组承担者成员被拒绝拥有 CreateProject 权限。因为个人承担者的权限会覆盖组承担者的权限，所以允许 Patrick 拥有 CreateProject 权限。
在解决组之间的冲突时，负权限优先。如果承担者在一个组中被允许拥有某权限，但在另一个组中被拒绝拥有该权限，则冲突的解决方式是拒绝该权限。
承担者随后会从父项 ACL 中继承权限集。如果在检查根 ACL 后，发现其并未为承担者提供明确的、可应用的正条目或负条目，则认为承担者在已解决的 ACL 中的权限集为空，即默认为已拒绝的权限。
权限的关键因素包括以下内容：
• 权限始终为以下三种状态之一：已允许、已拒绝或已清除。
• 服务器始终使用其在 ACL 层次结构中找到的最具体的权限。例如，与已清除的权限相比，已允许和已拒绝的权限更为具体。
• 已定义的权限优先于继承的权限。
• 根据继承规则，优先使用明确拒绝的权限，即便已通过另一个承担者允许该权限，亦是如此。但清除某个权限后，仍然可以通过另一个承担者或者父项 ACL 明确允许该权限。
• 为用户承担者明确指定的权限优于其所属的组的权限。分配给个人权限始终覆盖个人所属组的权限。
• 一个承担者最多可以有一个正 ACL 条目和一个负 ACL 条目。任何承担者不能对同一权限有多个正的或负的 ACL 条目。
• 如果特定承担者没有条目，则认为该承担者在已解决的 ACL 中的权限集为空。承担者随后会从父项 ACL 中继承权限集。
• 在解决组之间的冲突时，负权限优先。如果承担者在一个组中被允许拥有某权限，但在另一个组中被拒绝拥有该权限，则冲突的解决方式是拒绝该权限。