2. ThingWorx权限模型基础

ThingWorx 的权限体系并不是“给某个人开某个菜单”这么简单，它由六个相互咬合的概念构成：用户（User）、用户组（User Group）、组织（Organization）、角色（Role）、权限集（Permission Set）与可见性（Visibility）。理解它们的关键，是先分清“谁在什么范围内、以什么身份、对什么对象、能做什么”。这四问分别对应主体、边界、身份、对象与动作，缺一不可。

六个概念各自解决什么问题

用户是权限的最小主体，代表一个可登录的账号，例如 zhang.san。用户本身几乎不直接承载权限，它更像一个“容器”，通过被放入用户组、被授予角色来获得能力。

用户组是权限批量管理的核心单位。把 20 个设备运维人员放进 Ops_Team 组，再给这个组授权，比逐个给 20 个用户授权可靠得多。用户组可以嵌套，也可以跨组织存在，但通常建议按“职责”而非“部门”划分，因为职责才决定权限需求。

组织是数据与资源的隔离边界，也是多租户治理的落点。ThingWorx 中常见的组织如 Acme_Corp、Partner_A。组织决定了“哪些物、哪些 Thing、哪些数据属于谁”，是可见性判断的第一道墙。一个用户可以被关联到多个组织，但在任一时刻，其操作都发生在某个确定的组织上下文中。

角色是“身份标签”，描述用户在某个组织或系统范围内扮演什么，例如 Administrator、Developer、Operator、Viewer。角色本身不直接等于权限，它是权限集的挂载点。把角色理解为“岗位”，把权限集理解为“岗位说明书”，就非常贴切。

权限集是真正描述“能做什么”的集合，由一条条权限项组成，例如“读取 Thing”“写入属性”“执行服务”“删除 Mashup”。权限集可以绑定到角色，也可以直接绑定到用户或用户组，但工程上推荐“权限集 → 角色 → 用户组 → 用户”的主链路，便于审计和复用。

可见性是权限的“前置过滤器”。它回答的是“这个对象能不能被看到”，而权限回答的是“看到之后能不能操作”。一个用户可能对某台设备有读取权限，但如果该设备不在其可见性范围内，他连对象都看不到。可见性通常由组织归属、可见性级别（如 Public、Private、Organization）以及显式共享共同决定。

层级关系：从边界到动作的四层结构

这六个概念不是平铺的，而是形成一条清晰的层级链：组织划定边界 → 用户组聚合主体 → 角色定义身份 → 权限集描述动作，而可见性贯穿始终，决定对象能否进入这条链的视野。可以用下面的关系图来理解它们的挂载与作用方向。

图中自上而下是“边界 → 主体聚合 → 身份 → 动作”的挂载顺序，而红色虚线框表示可见性对每一层都施加约束。需要特别注意的是：用户组和角色之间不是包含关系，而是“授予”关系。一个用户组可以被授予多个角色，一个角色也可以被授予多个用户组，这种多对多关系正是权限模型灵活性的来源，也是容易配错的地方。

一个可落地的配置示例

假设 Acme_Corp 组织下有一支设备运维团队，需要让成员能查看设备状态、执行重启服务，但不能修改 Thing 模型。可以按如下方式配置：

• 创建用户组 Ops_Team，成员为 zhang.san、li.si。
• 创建角色 Operator，将其可见性范围设为 Acme_Corp 组织内。
• 创建权限集 Ops_Basic，包含权限项：Thing.Read、ThingProperty.Read、Service.Invoke（仅限 RestartService）。
• 将 Ops_Basic 绑定到 Operator 角色。
• 将 Operator 角色授予 Ops_Team 用户组。

配置完成后，zhang.san 登录后只能看到 Acme_Corp 组织内被标记为可见的设备，能读取属性、能调用重启服务，但尝试编辑 Thing 模板时会被拒绝。这个“能看、能做、不能改”的边界，正是可见性与权限集共同作用的结果。

常见误区与边界澄清

第一个误区是把角色当权限用。角色只是标签，真正决定能力的是它挂载的权限集；给用户直接挂权限集虽然可行，但会绕过角色层，导致审计困难。第二个误区是忽略可见性的前置性。很多“权限明明给了却看不到”的问题，根源不在权限集，而在对象可见性未覆盖该用户所在组织。第三个误区是组织与用户组混用：组织管数据隔离，用户组管人员聚合，二者职责不同，不应互相替代。

理解这六个概念及其层级关系，是后续学习多租户隔离、权限继承与冲突排查的基础。只有先看清“谁在什么边界内、以什么身份、对什么对象、能做什么”，才能在 ThingWox 中把权限配得既安全又可维护。