ServiceUserRole

ServiceUserRole は、製品にサインアップした end-user、すなわち ServiceUser に付与する権限のまとまりです。Content Type・Content・Media に対して何を(読み取り・作成・編集・削除)できるか、Script を実行できるか、そして特定の Content Type のみ、自分が作成したもののみ、といった範囲を絞り込むフィルターを 1 つのリソースにまとめます。使えるアクションはマップごとに異なります(下の 権限マップ の表)。この権限は 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 そのもの(スキーマ)に対する権限マップです。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: そのルールが適用される対象を リソース自身 1 つに限定します。contentType マップでは特定の Content Type 1 つ、script マップでは特定の Script 1 つを意味します。
• contentType: その Content が 属する Content Type に限定します。Content Type を指す Refer を入れます。
• createdBy: 特定のユーザーが作成したリソースのみに限定します。sys.id に特定の id を入れるとその人が作成したものだけに、予約値 :self を入れると「いま呼び出している ServiceUser が作成したものだけ」に限定されます。
• tag: 特定の Tag が付いたリソースのみに限定します。

どのフィルターがどの権限マップで有効かは SpaceRole と同じで(contentType マップは self、content マップは contentType で対象を指定します)、合わないフィルターを入れるとロールの保存が拒否されます。マップごとの表は SpaceRole の権限マップ にあります。

createdBy フィルター(:self を含む)を ACDA で適用する場合は、対象の 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 の 4 つです。フィルターキーや :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 に指定して、その会員 1 名だけに適用します。ServiceLogin の defaultRole を一般会員ロールにしておけば、新しくサインアップする会員が管理者ロールを受け取ることはありません。

Media も同じ方法です。media マップのアクションから createdBy を外すと、他の会員がアップロードしたファイルまで対象になります。ただし contentType フィルターは content マップでのみ使うため、media マップには入れません。

script (Script 権限)

script は Script に対する権限マップで、構造は content・media と同じです。ただし ServiceUser が Script に対してできるのは 実行 だけです(オーサリング、すなわち作成・修正・削除は CMA の Weegloo User 専用です)。そのため ServiceUserRole の script で使えるアクションは All と Execute の 2 つだけです。

サインアップ会員が Script を実行できるようにするには、次のように書きます。

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

ルールのフィルターとして使えるのは self(特定の Script 1 つ)と createdBy の 2 つです。contentType・tag は Script に付かない軸なので、入れるとロールの保存が拒否されます。会員に特定の Script 1 つだけを実行させるには、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 用の権限のまとまり(同じ権限マップ構造)。