Teamcenter学习平台正式上线(https://www.plmvision.top)，安装配置实施开发源码仓库，全套学习教材！关注公众号发送“二维码“咨询加入！

前言：为什么简单的 RWX 不够用？

在文件系统（如 NTFS 或 Linux）中，权限是静态的：文件 A 属于用户 B，权限是 755（读写执行）。
但在 PLM 领域，权限必须是动态上下文感知的。

场景：

• 当图纸是“正在设计”状态时，只有张三（作者）能改。

• 一旦张三点击“发布”流程，图纸状态变为“已发布”，此刻瞬间，张三立刻失去修改权，而车间李四立刻获得查看权。

• 如果这需要管理员手动去改 ACL，系统早就崩溃了。

Teamcenter 的 Access Manager (AM) 通过引入 Rule Tree（规则树） 解决了这个问题。它不是在查表，而是在运行一套决策算法。

一、 Rule Tree 算法：权限不是存出来的，是算出来的

TC 的权限判断机制是一个**遍历（Traversal）**过程。它维护了一棵巨大的逻辑判断树。当你要操作一个对象时，AM 引擎会带着你的请求，从树根（Root）开始往下跳。

1. 树的层级结构（The Hierarchy）

这棵树的节点不是随意的，它通常遵循 “从一般到特殊” 的逻辑深度：

1. Level 1 – 对象类型 (Has Class):

• 是 ItemRevision？还是 Dataset？还是 Folder？

• Has Status(Released)？（有没有发布状态？）

• In Project(ProjectA)？（是否属于某项目？）

• 你是 Owner（所有者）吗？

• 你是 Group Member(Engineering) 吗？

• 还是 World（任何人）？

2. 遍历算法 (The Path)

假设有一个对象：Bolt-Revision-A，状态为 Released，所有者是 UserA。
UserA 试图修改它。

AM 引擎的伪代码逻辑如下：

def check_access(user, object, action):    current_node = Root
    # 步骤 1: 匹配类型    if object.is_type("ItemRevision"):        current_node = Node_ItemRevision
    # 步骤 2: 匹配状态 (更具体的条件优先)    # AM 会检查该节点下的所有分支，寻找匹配当前对象特征的分支    if object.has_status("Released"):        current_node = Node_Released    else:        current_node = Node_Working
    # 步骤 3: 获取该节点的 ACL (Access Control List)    # 注意：这里不仅看叶子节点，TC 可能会累加路径上的权限（视配置而定，通常是“最近匹配原则”）    acl = current_node.get_named_acl()
    # 步骤 4: 裁决    return acl.evaluate(user, action)

核心逻辑： 并不是给每个对象身上贴 100 个条目，而是给对象分类。所有 Released 状态的 ItemRevision 共享同一个规则节点。这就是为什么 TC 可以管理亿级数据而权限检查依然能在毫秒级完成。

二、 Named ACL：权限的“面向对象封装”

在早期的简陋系统中，我们可能会写硬编码：User A can Read, Write。
在 TC 中，权限被封装成了对象 —— Named ACL (命名权限集)。

1. 什么是 Named ACL？

它是一个模板。比如定义一个叫 “Working_Access” 的 ACL：

• Owner: Read, Write, Delete, Change_Owner… (全权)

• Group: Read (组内可见)

• World: Null (其他人不可见)

再定义一个叫 “Released_Access” 的 ACL：

• Owner: Read (只读！写权限被剥夺)

• Group: Read

• World: Read

2. 挂载 (Attachment)

我们将 Working_Access 挂在规则树的 Has Status(Working) 分支下；
将 Released_Access 挂在 Has Status(Released) 分支下。

结果：当流程引擎（Workflow）将对象状态改写的一瞬间，对象自动掉落到规则树的另一条分支，引用的 ACL 瞬间切换。没有修改任何一行数据库记录的权限字段，但权限逻辑全变了。

三、 Grant vs Revoke 的博弈：Merge Logic

这是 AM 中最烧脑的部分。如果一个用户同时满足多条规则怎么办？
例如：张三既是 Owner，又是 Engineering Group 的成员。

• 规则 A (Owner): Grant Write.

• 规则 B (Group): Revoke Write.

TC 的裁决逻辑通常遵循 “最特定匹配 (Most Specific Match)” 或 “累加计算”。但在 AM 树中，有一种特殊的机制：

1. 规则的覆盖 (Override)

通常，树的层级越深，优先级越高。
如果在 ItemRevision 层级说“大家都能读”，但在 ItemRevision -> Has Status(Secret) 层级说“只有经理能读”。
那么对于绝密文件，深层规则覆盖浅层规则。

2. Grant 与 Revoke 的数学运算

最终的权限 = (Σ Grants) – (Σ Revokes)

• Grant (授予)：开启某个开关。

• Revoke (剥夺)：强制关闭某个开关（优先级通常高于 Grant）。

• System Deny：硬性拒绝。

经典案例：
某公司规定，所有 Released 图纸，作者也不能删。

• ACL 配置：Owner -> Grant Read, Revoke Delete。
  即使 Owner 这种身份在系统底层默认拥有极大权力，一旦 ACL 中显式配置了 Revoke，这个“否决票”是一票否决制的。

四、 偷师目标：构建基于规则的权限引擎

如果你是一个架构师，正在设计一套企业级 SaaS 系统的权限模块，不要再只用 RBAC（基于角色的访问控制）了。你应该偷师 TC 的 ABAC（基于属性的访问控制）思想。

设计要点：

1. 解耦：不要把权限写死在用户表或数据表里。

2. 规则树：建立一个独立的决策树引擎。

• 输入：Who (User), What (Object Metadata), Context (Time/Status)

• 输出：Permission Mask (010101)

总结

Teamcenter 的 Deployment Center 可能让你头疼，但它的 Access Manager 绝对是艺术品。它用静态的树状结构，完美承载了动态变化的业务流转权限需求。