Skip to Content
Organizations役割と権限の範囲

役割と権限の範囲

OpenFactory は、組織、部門、チームで独立した役割を保存します レベル。ロール名はスコープを表します。それは普遍的な許可ではありません すべての API または製品機能に自動的に適用されます。

スコープモデル

organization membership: owner | admin | member └── unit membership: unit_admin | base_creator | base_approver | member └── team membership: team_lead | variant_creator | variant_deployer | variant_user

組織のメンバーシップは外側の境界です。ユーザーは組織である必要があります 管理者がユニットまたはチームの 1 つにメンバーを追加する前に、メンバーを追加する必要があります。 メンバーシップは各レベルで個別にチェックされます。ユニットやチームを推測しないでください 別のコンテキストで示されている組織の役割からの役割。

組織の役割

現在の組織管理 API では、次の権限が強制されます。

操作オーナー管理者メンバー
組織、メンバー、グループ、ユニット、チームを表示するはいはいはい
組織名または説明を編集はいはいいいえ
グループを作成、編集、削除し、グループ メンバーを管理するはいはいいいえ
通常のメンバーを招待または削除するはいはいいいえ
通常のメンバー/管理者の役割を変更するはいはいいいえ
所有者を招待または昇格するはいいいえいいえ
既存の所有者を変更または削除するはいいいえいいえ
ユニットの作成または削除はいはいいいえ
組織を削除するはいいいえいいえ
組織を離れるはい、唯一の所有者でない限りはいはい

組織には複数の所有者が存在する場合があります。 API は単独所有者を防止します 別の所有者が存在するか、組織が削除されるまで、離脱することはできません。そこに この API には個別の「所有権の譲渡」アクションはありません。所有者が別の所有者を変更する メンバーの役割を owner に変更すると、意図したとおりに以前の所有者を変更または削除できます。

ユニットの役割

組織の所有者と管理者は、すべてのユニットを管理できます。ユニット内では、 現在の組織管理 API は unit_admin に次の機能を付与します 管理操作:

  • ユニットを編集します。
  • ユニットメンバーの役割を追加、削除、および変更します。
  • そのユニット内のチームを作成、編集、削除します。
  • そのユニットのチームメンバーを追加および管理します。

ユニット自体を削除できるのは、組織の所有者または管理者のみです。

base_creatorbase_approver、およびユニット member は、ロール ラベルとして格納されます。 基本イメージのワークフロー ポリシー。組織の CRUD ルート自体は 他の場所でのすべての作成、承認、またはデプロイメントアクションがこれらを強制することを証明します。 ラベル。特定のビルドまたは承認の承認動作を確認する コントロールとして依存する前にワークフローを確認してください。

チームの役割

組織の所有者/管理者と親ユニットの unit_admin はチームを管理できます メンバーシップ。 team_lead では次のことができます。

  • チームの名前または説明を編集します。
  • チームメンバーの追加と削除。
  • チームメンバーの役割を変更します。

team_lead は、現在の組織 API を通じてチームを削除できません。 その操作は組織の所有者/管理者または親のために予約されています unit_admin

variant_creatorvariant_deployer、および variant_user は、意図した内容を表します バリアントワークフローの責任。それらは、すべてのことを証明するものとして読まれるべきではありません。 バリアント エンドポイントは、完全な作成/編集/デプロイ マトリックスを強制します。正確にテストする デプロイされたリリースのワークフローと拒否されたパス。

グループは異なります

グループは組織レベルの共有コレクションであり、別の役割階層ではありません。 所有者と管理者はグループを作成し、グループのメンバーシップを管理します。すべての組織 メンバーはグループとそのメンバーをリストできます。グループのメンバーシップは、 ユーザーを組織管理者、部門管理者、またはチームリーダーにします。

ロールを安全に変更する

  1. 対象となる組織、ユニット、チームを確認します。
  2. 3 つのスコープすべてでユーザーの現在有効なメンバーシップを記録します。
  3. ロールの変更を 1 つ適用します。
  4. そのユーザー独自の操作で、許可された操作と拒否された操作の両方をテストします。 セッション。
  5. キャッシュされた UI 状態と既存のセッションに変更が反映されていることを確認します。
  6. ポリシーで必要な場合は、役割ラベルの外側に監査レコードを保持します。

パス拒否テストを行わずにラベルを変更することは、次のことを示す十分な証拠ではありません。 最小限の特権が強制されます。

一般的なエッジケース

  • 管理者は、誰かを所有者に昇格させたり、既存の所有者の役割を変更したりすることはできません。
  • ユーザーは、所属するまでユニットまたはチームに追加できません。 組織。
  • ユニットおよびチームメンバーは自分自身を削除することができます。組織のメンバーシップは残ります 別途取り外さない限り。
  • 組織のメンバーシップを削除するには、古いユニット、チーム、 リリース内のグループ、共有、セッション効果。
  • UI バッジの色はプレゼンテーションであり、セキュリティ制御ではありません。いつも頼りにしてる サーバー側の認証と拒否されたパスのテスト。