ServiceUserRole

ServiceUserRole 是分配给在产品中注册的 end-user，即 ServiceUser 的权限集合。它在一个资源中描述对 Content Type、Content、Media 可以执行哪些操作（读取、创建、编辑、删除）、能否执行 Script，以及把范围收窄为仅某些 Content Type、仅自己创建的内容等的过滤条件。可以使用的操作因映射而异（见下面的 权限映射 表格）。该权限作用于 ServiceUser 调用的 ACMA/ACDA。

它与 SpaceRole 的定位不同。SpaceRole 是 Weegloo User（内容工作室用户）的权限集合，作用于 CMA/CDA；ServiceUserRole 是在产品中注册的 ServiceUser 的权限集合，作用于 ACMA/ACDA。创建出来的 ServiceUserRole 本身不会应用到任何人身上。需要把它指定到 ServiceLogin 的默认角色（defaultRole），或者绑定到 ServiceUser 的 roleOverride 才会生效。

资源结构

下面是 ServiceUserRole "买家" 的单个查询响应。它包含 sys（系统属性），以及用于定义权限的本体属性 contentType、content、media、script。

{
  "sys": {
    "id": "3trmXRLXeZN2RTHvVj3hFDN5546vbp",
    "type": "ServiceUserRole",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T12:40:36.944Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T12:40:36.944Z",
    "version": 1
  },
  "name": "买家",
  "description": "可读取已发布商品的会员",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } },
  "script": {}
}

主要键：

• contentType：针对 Content Type 本身（schema）的权限映射。ServiceUser 只会读取表单，因此只定义 Read。
• content：针对 Content（内容数据）的权限映射。上面的示例只允许读取特定 Content Type 的 Content。
• media：针对 Media（文件、图片）的权限映射。
• script：针对 Script（声明式后端端点）的权限映射。ServiceUser 对 Script 只能执行（Execute）。

与 SpaceRole 不同，ServiceUserRole 没有承载 Space 设置访问权限的 settings，因为 ServiceUser 不处理 Space 设置。此外也没有表示是否为内置项的 sys.isLocked。

系统属性 (sys)

所有 ServiceUserRole 都把公共系统属性放在 sys 对象中。space、createdBy、updatedBy 以 Refer 形态（{ "sys": { "id", "type": "Refer", "targetType" } }）出现。

ServiceUserRole 是没有发布概念的设置类资源。因此与 Content、Media 不同，sys 中没有 publish、archive、status，只有 version。version 在每次修改 ServiceUserRole 时递增。与 SpaceRole 不同，它也没有 sys.isLocked。

权限映射：contentType、content、media

contentType、content、media、script 各自都是以操作为键的映射。每个操作的值是一个包含 Allow（允许）和 Deny（拒绝）规则数组的对象。映射的结构与 SpaceRole 相同，但可以使用的操作因映射而异，而且比 SpaceRole 更窄。

All 一次性指代该映射中可以使用的全部操作。把表中没有的操作作为键放进去时，角色保存会被拒绝。发布系列（Publish、Unpublish、Archive、Unarchive）在任何映射中都没有，是因为会员创建的 Content、Media 在创建时就会立即发布（参见 ACMA）。

不存在名为 Save 的操作。修改权限是 Edit，而 Save 是 Webhook 订阅的事件名称。

"content": {
  "Read":   { "Allow": [ /* 规则 */ ], "Deny": [ /* 规则 */ ] },
  "Edit":   { "Allow": [ /* 规则 */ ] }
}

每个规则（rule）对象都带有用于收窄权限范围的可选过滤条件。

• self：把该规则适用的对象限定为资源自身这一个。在 contentType 映射中表示某一个特定的 Content Type，在 script 映射中表示某一个特定的 Script。
• contentType：限定为该 Content 所属的 Content Type。填入指向 Content Type 的 Refer。
• createdBy：限定为仅由特定用户创建的资源。在 sys.id 填入特定 id 表示仅限该用户创建的内容，填入保留值 :self 则限定为"仅当前调用的 ServiceUser 所创建的内容"。
• tag：限定为仅带有特定 Tag 的资源。

哪个过滤条件在哪个权限映射中有效与 SpaceRole 相同（contentType 映射用 self 指定对象，content 映射用 contentType 指定），放入不匹配的过滤条件时，角色保存会被拒绝。按映射区分的表格见 SpaceRole 的权限映射。

在 ACDA 中使用 createdBy 过滤条件（含 :self）时，目标 Content Type 的 publishWithAuthor 必须为 true。 ACDA 依据发布快照中的 sys.createdBy 判定该过滤条件，而当 publishWithAuthor 为默认值 false 时，快照中没有作者，因此 Allow 规则不会匹配到任何内容（会员会得到空结果），Deny 规则也无法过滤掉任何人。相比之下，ACMA（管理）依据草稿的 sys.createdBy 判定，与该设置无关，因此同一规则即使在 ACMA 中生效，也可能在 ACDA 中出现偏差。publishWithAuthor 必须在会员发帖之前开启，且不追溯。请参考 Content Type 的 publishWithAuthor 说明。

空的 Allow 数组 [] 表示对该种类的全部资源允许该操作。由于过滤条件为空、没有可过滤的内容，因此该操作对所有资源开放。

与 SpaceRole 不同，ServiceUserRole 没有 settings。权限映射有 contentType、content、media、script 四种。过滤键以及 :self 的含义等权限映射的编写方法，请一并参考使用相同结构的 SpaceRole 说明。不过，可以使用的操作以上面的表格为准，与 SpaceRole 不同。使用 :self 把范围收窄为仅能编辑本人创建的 Content 的示例，见正下方的 普通会员角色与管理员角色。

过滤键（self、contentType、createdBy、tag）以及 :self 的含义，均以 SpaceRole 的权限规则定义为准。ServiceUserRole 的 :self 解析为仅限当前 ServiceUser 所创建的内容。操作列表不遵循 SpaceRole，而是以上面的表格为准。

普通会员角色与管理员角色

会员能否处理其他会员的资源，取决于规则的 createdBy 过滤条件。即便是同一个操作，在 createdBy 中填入 :self 时，该操作只以发起调用的会员本人创建的内容为对象；不填 createdBy 时，则连其他会员创建的内容也纳入对象范围。

给普通会员的角色把 Edit 和 Delete 限定为 :self。

"content": {
  "Edit": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  },
  "Delete": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  }
}

对于要充当管理员的会员，则另外创建一个在相同操作上去掉 createdBy 的角色。下面这个角色只把删除开放到其他会员创建的内容，而编辑仍保留为本人创建的内容。

"content": {
  "Edit": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  },
  "Delete": {
    "Allow": [
      { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
    ]
  }
}

这样创建出来的角色，指定到 ServiceUser 的 roleOverride，就只会应用于那一位会员。把 ServiceLogin 的 defaultRole 设为普通会员角色后，新注册的会员不会拿到管理员角色。

Media 也是同样的方式。在 media 映射的操作中去掉 createdBy，其他会员上传的文件也会纳入对象范围。不过 contentType 过滤条件只用于 content 映射，因此不要放进 media 映射。

script (Script 权限)

script 是针对 Script 的权限映射，其结构与 content、media 相同。不过 ServiceUser 对 Script 能做的只有执行（创作，即创建、修改、删除，仅限 CMA 的 Weegloo User）。因此在 ServiceUserRole 的 script 中可以使用的操作只有 All 和 Execute 两个。

要让注册会员能够执行 Script，可以这样写。

"script": {
  "Execute": { "Allow": [] }
}

可以用作规则过滤条件的是 self（某一个特定的 Script）与 createdBy 这两个。contentType、tag 是不附加于 Script 的轴，放入后角色保存会被拒绝。若只想允许会员执行某一个特定的 Script，就在 Execute 的 Allow 中放入指向该 Script 的 self 规则。

"script": {
  "Execute": {
    "Allow": [
      { "self": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } } }
    ]
  }
}

Script 本身的结构以及执行端点见 Script 资源与端点，操作的完整列表见 SpaceRole 的 script 权限。

错误

以下是处理 ServiceUserRole 时会遇到的错误码。所有资源共通的错误码，请参见通用错误。

API

下面所有端点的基准 URL 都是 https://cma.weegloo.com/v1，并且需要在 Authorization 头中提供用于向 CMA 认证的 Bearer 令牌。修改角色（PUT、PATCH）时，为实现乐观并发控制，必须一并发送 X-Weegloo-Version 头（当前资源的 sys.version）。创建和删除不需要该头。

相关文档

• ServiceUser：领取此角色的注册会员（roleOverride）。
• ServiceLogin：通过默认角色（defaultRole）指定 ServiceUserRole。
• SpaceRole：面向 Weegloo User 的权限集合（相同的权限映射结构）。