4. 角色与角色对象设计
在 Teamcenter 的访问控制体系中，Role（角色）与 Role Object（角色对象）是最容易被混淆、却又最影响权限治理质量的一对概念。很多项目在初期只建了少量角色，把所有权限都堆在角色上，结果随着组织扩张，权限模型迅速失控：同一个角色在不同产品线、不同项目、不同工厂下需要完全不同的权限，却只能靠不断复制角色来应付。要避免这种局面，必须先把 Role 与 Role Object 的职责边界讲清楚。
一、Role 与 Role Object 的本质区别
Role 描述的是“一个人在业务中承担什么职责”，例如设计工程师、工艺工程师、审核员、项目经理、资料管理员。它回答的是“我是谁、我负责什么”。在 Teamcenter 中，Role 通常作为访问管理器（Access Manager）规则中的主体之一，与 Group、User 一起参与权限判定。
Role Object 描述的是“这个职责作用在哪个业务对象上”。它把角色与具体对象绑定，例如“A 产品线的设计工程师”“B 项目的审核员”“某工厂的工艺工程师”。Role Object 回答的是“我在哪个范围内、对哪类对象行使这个职责”。
两者的关系可以概括为：Role 是职责的抽象定义，Role Object 是职责在具体业务对象上的实例化。Role 决定“能做什么”，Role Object 决定“对什么做”。在权限判定时，Teamcenter 会把用户所属的 Group、Role 以及对象上挂接的 Role Object 一起纳入计算，最终决定该用户对该对象拥有哪些权限位（如读、写、删、改状态、授权等）。
二、为什么不能只用 Role 而不用 Role Object
假设企业只有“设计工程师”这一个 Role，所有设计人员都挂这个角色。当 A 产品线的设计工程师需要修改 A 产品线的装配，而 B 产品线的设计工程师不应看到 A 产品线的数据时，仅靠 Role 无法区分。此时有两种做法：一是为每条产品线各建一个 Role，如“A设计工程师”“B设计工程师”，角色数量会随产品线数量线性膨胀；二是保留一个“设计工程师”Role，通过 Role Object 把职责绑定到具体产品线对象上，角色数量保持稳定，范围由对象决定。
后者才是可治理的做法。Role 的数量应当与“职责种类”相关，而不是与“业务对象数量”相关。职责种类通常有限，而业务对象会持续增长。把增长的部分交给 Role Object，权限模型才能长期稳定。
三、基于业务职责设计角色对象的方法
设计 Role Object 时，建议按以下思路推进，而不是先打开 Access Manager 就开始写规则。
第一步，梳理职责清单。从业务流程出发，列出每个环节需要“做什么”。例如：设计工程师需要创建和修改 Item、ItemRevision；审核员需要读取并批准状态；工艺工程师需要读取设计数据并创建工艺对象；项目经理需要读取全部数据并授权他人。职责清单是 Role 的来源。
第二步，确定职责的作用范围。对每项职责追问：它作用在哪个组织、哪条产品线、哪个项目、哪个工厂？作用范围就是 Role Object 的绑定对象。范围可以是产品线、项目、工厂、部门，也可以是某个具体对象。范围越清晰，Role Object 越容易维护。
第三步，建立 Role 与 Role Object 的对应关系。一个 Role 可以对应多个 Role Object，一个 Role Object 也可以被多个用户或组引用。对应关系应记录在权限设计表中，而不是只存在于管理员脑中。下表给出一个示例结构，字段可根据项目实际调整。
| 职责（Role） | 作用范围（Role Object 绑定对象） | 权限位 | 适用对象类型 |
|---|---|---|---|
| 设计工程师 | A 产品线 | 读、写、改状态 | Item、ItemRevision |
| 审核员 | B 项目 | 读、批准状态 | ItemRevision、Dataset |
| 工艺工程师 | 某工厂 | 读、创建工艺对象 | Process、BOP |
| 项目经理 | C 产品线 | 读、授权 | 全部对象 |
第四步，验证权限继承链。Role Object 挂到对象上之后，权限并不是简单叠加，而是按 Access Manager 规则逐条判定。需要验证：用户通过 Group 继承的权限、通过 Role 获得的权限、通过 Role Object 获得的权限，在目标对象上是否产生预期结果。验证时应选择典型对象，分别用不同用户登录，观察读、写、删、改状态四个权限位的实际表现。
四、角色在权限继承中的作用
Teamcenter 的权限继承不是单一链条，而是多来源汇聚。用户最终权限来自以下几个来源：用户直接授权、用户所属 Group 的授权、用户所属 Role 的授权、对象上挂接的 Role Object 授权，以及对象状态和规则优先级的影响。Role 在其中扮演“职责模板”的角色：它定义了某类职责默认拥有哪些权限位，Role Object 则把这个模板实例化到具体对象上。
当用户同时属于多个 Group 和多个 Role 时，权限判定会按规则逐条匹配。匹配到允许规则则获得对应权限，匹配到拒绝规则则失去对应权限。因此，Role 的设计必须与 Group 的设计配合：Group 通常表达组织归属，Role 表达职责，Role Object 表达职责的作用范围。三者分工明确，权限模型才不会互相打架。
五、一个可复用的设计检查清单
在完成 Role 与 Role Object 设计后，可用以下清单做一次自查：
- 每个 Role 是否对应一个明确的业务职责，而不是一个组织或一个人？
- 每个 Role Object 是否绑定了明确的作用范围对象，而不是“全局”？
- Role 的数量是否与职责种类相关，而不是与产品线或项目数量相关？
- 权限设计表是否记录了 Role、Role Object、权限位、对象类型的对应关系？
- 是否用典型用户验证过读、写、删、改状态四个权限位的实际结果？
- 是否存在用 Role 代替 Group、或用 Role Object 代替 Role 的情况？
把 Role 与 Role Object 的边界划清楚，是后续所有权限规则能够稳定运行的前提。Role 保持稳定，Role Object 随业务对象扩展，权限模型才能在组织变化和项目增长中持续可控。