2. Teamcenter权限模型基础

Teamcenter 的权限判定不是“给某个人开一个开关”，而是把主体（谁）、客体（对什么）、动作（做什么）和条件（在什么范围内）四件事组合起来计算。理解这一点，后续所有授权配置、排障和治理才有共同语言。本节先把六个核心概念拆开，再说明它们如何串成一次访问判定。

一、六个核心概念各自是什么

用户（User）是登录系统的最小身份单位，对应一个真实账号，例如 zhangsan。用户拥有登录名、口令策略、默认组等属性。用户本身不直接承载大量权限，它主要通过“属于哪些组、在哪些组中担任哪些角色”来获得能力。

组（Group）是按组织或职能划分的人员集合，例如 Design（设计组）、Manufacturing（工艺组）、Quality（质量组）。组解决“同一类人批量管理”的问题。一个用户可以同时属于多个组，登录时选择一个当前组，权限判定会结合当前组上下文进行。

角色（Role）描述“在某个组里承担什么职责”，例如 Designer、Approver、Viewer。角色是权限的载体：权限通常授予角色，而不是授予个人。用户与组、角色的组合关系，构成 Teamcenter 中常说的“用户—组—角色”三元组，它是权限计算的基本主体单元。

角色对象（Role Object）是角色在具体业务对象上的实例化体现。例如在某个产品结构或某个文件夹上，把 Designer 角色与一个具体对象关联，就形成该对象上的角色对象。它把“抽象角色”落到“具体数据”上，使权限可以按对象精细控制。

权限集（Access Set / Privilege Set）是一组权限条目的集合，规定“允许或拒绝哪些操作”，如读、写、删除、修改状态、导出等。权限集通常与角色对象绑定，决定该角色在该对象上能做什么。

访问管理器（Access Manager）是 Teamcenter 中集中定义和管理访问规则的工具与机制。它把用户、组、角色、对象类型、权限集、条件等组织成可维护的规则，并在访问发生时执行判定。访问管理器不是“另一个权限”，而是权限规则的定义与执行中心。

二、它们之间的关系：从身份到判定的链路

一次访问请求的判定逻辑可以概括为：用户登录后确定当前组，系统识别用户在该组中的角色，找到目标对象上的角色对象，读取其绑定的权限集，再由访问管理器结合对象类型、状态、条件等计算最终结果。若任一环节缺失或不匹配，权限就可能被拒绝。

三、权限判定的基本逻辑

Teamcenter 的权限判定遵循“主体 + 客体 + 动作 + 条件”四要素模型。主体是当前登录用户及其当前组、角色；客体是访问目标，如某个零件版本、某个文件夹；动作是读、写、删除、签审等；条件是对象状态、时间、项目归属等约束。访问管理器把四者代入规则，输出允许或拒绝。

需要特别注意两点。第一，权限是叠加与覆盖并存的：用户可能通过多个组、多个角色获得权限，系统会综合计算；但显式拒绝通常优先于允许。第二，当前组上下文会改变判定结果：同一用户切换到不同组，其角色和权限集可能不同，因此“同一个人为什么昨天能改、今天不能改”往往与当前组或对象状态变化有关。

四、一个可操作的判定示例

假设用户 zhangsan 属于 Design 组，在该组中担任 Designer 角色。目标对象是零件 P-1001 的 A 版本，当前状态为“设计中”。该对象上存在角色对象 Designer@P-1001，绑定的权限集包含“读、写、修改状态”，但不含“删除”。

当 zhangsan 尝试删除 P-1001 时，访问管理器识别到：主体为 zhangsan/Design/Designer，客体为 P-1001，动作为删除，条件为“设计中”状态。由于权限集中没有删除条目，判定结果为拒绝。若 zhangsan 尝试修改该零件属性，则命中“写”权限，判定为允许。这个例子说明：权限不是按人整体开关，而是按对象、按动作、按条件逐项计算。

五、常见误区与排查方向

实际工作中，权限问题常被误判为“账号没权限”。更准确的排查顺序是：先确认用户当前组是否正确，再确认该组中是否担任了预期角色，然后检查目标对象上是否存在对应角色对象，接着查看角色对象绑定的权限集是否包含所需动作，最后确认访问管理器中是否有条件规则或显式拒绝覆盖了允许。按这条链路逐段核对，绝大多数权限异常都能定位到具体环节，而不是停留在“权限不够”的模糊结论上。

掌握这六个概念及其关系，是后续学习权限规则编写、角色设计、项目级授权和权限治理的前提。只有先看清判定链路，才能在配置和排障时做到有据可依、逐段验证。