現在の Organization
私たちは、すべてのエントリポイントで現在の Organization ID が定義されるようにします。これらのエントリポイントには、Web リクエスト、バックグラウンドジョブ、スケジュールされたタスクが含まれます。
Web リクエスト
Rails コントローラー、Grape API、GraphQL、ActionCable が含まれます。
Web リクエストでは、現在の Organization は以下の優先順位で決定されます。詳細はサブセクションに記載しています。
- パスパラメーター(例:
/o/my-org/my-group、/my-group/my-project) - ヘッダーフィールド(
X-GitLab-Organization-ID) - User のホーム Organization(
user.organization_id)。 - デフォルト Organization(ID = 1)
この優先順位によって Organization コンテキストが解決されます。User コンテキストと Nil コンテキストは、それぞれ独立した別のコンテキストです。リクエストコンテキストを参照してください。ルートは Default Organization にフォールバックせず、いずれかのコンテキストへ解決できます。どのルートをそのように扱うべきかは、まだ決まっていないルートごとの明示的な判断であり、このページでは解決しません。
パスパラメーター
現在の Organization はリクエストされたリソースの親 Organization になります。
Organization は Organization スコープ o/ を使用してパスに付加されます(例:
https://gitlab.com/o/my-org/my-group/my-project/-/issues/1234)。この
決定の詳細はOrganization パススコープ ADRにあります。
例:
/o/my-organization/my-group: Organization はmy-organizationになります/o/my-organization/engineering/backend: プロジェクトengineering/backendがスコープされているため、Organization はmy-organizationになります。/top-level-group/my-project:top-level-groupがmy-organizationに移動されている場合、Organization はmy-organizationになります。
ヘッダーフィールド
X-GitLab-Organization-IDヘッダーに含まれる Organization コンテキスト- フロントエンドの JavaScript が AJAX/API 呼び出しにコンテキストを自動的に含める
- インタラクティブセッション中に一貫したコンテキストを維持する
User のホーム Organization
User のホーム Organization(organization_id)は、常に 1 つの Organization だけを指します。つまり、所有権は常に排他的です。メンバーシップもその Organization に限定されるかどうかは、その Organization が隔離されているかによって決まります。ユーザーのホーム Organizationを参照してください。
認証された曖昧なリクエストのフォールバックとして使用されます。
デフォルト Organization
これは、より上位の優先順位マッピングで処理されない未認証リクエストのフォールバックです。
デフォルト Organization は 1 つの Cell にのみ存在するため、デフォルト Organization の使用は Cells 互換性を損ないます。
API リクエスト
REST および GraphQL リクエストは /api/v4 および /api/graphql のままです。
各リクエストには以下のいずれかで Organization コンテキストを指定する必要があります。
X-GitLab-Organization-IDヘッダー- 使用されたシークレット(Personal Access Token など)に関連付けられた Organization
パラメーターがない場合はデフォルト Organization へのフォールバックが発生します。
バックグラウンドジョブ
ジョブは現在の Organization コンテキストとともにエンキューされ、実行中に自動的に適用されます。
例:
# Sidekiq client middleware - preserves context when enqueuing
class OrganizationContextClientMiddleware
def call(worker_class, job, queue, redis_pool)
# Capture current organization context
job['organization_id'] = Current.organization_id
yield
end
end
# Sidekiq server middleware - restores context during processing
class OrganizationContextServerMiddleware
def call(worker, job, queue)
organization_id = job['organization_id']
raise "Missing organization context" unless organization_id
# Set thread-local context that query executor will use
Current.organization_id = organization_id
yield
ensure
Current.organization_id = nil
end
end
スケジュールされたタスク
Cron ジョブは現在の Organization を定義する必要があります。この要件をスキップする方法が提供されますが、典型的なケースではなく例外的な状況と見なされます。
例外
現在の Organization は一種のグローバル実行コンテキストとして定義されます。現在の Organization は常に定義されることが期待されますが、不可能または望ましくないと認められる状況もあります。
- 管理者操作
- システム全体の管理タスクは明示的なコンテキスト免除ブロックを使用します
- スケジュールされたタスク
- Cron ジョブは、現在の Organization なしでジョブを初期化し、その後 Organization のバッチごとに現在の Organization を定義する可能性があります。
例外の例:
class DropPendingBuildsWorker
def perform
# Process each organization's builds with proper context
organizations_with_pending_builds.each do |org_id|
# Set thread-local context for automatic query wrapping
Current.organization_id = org_id
process_builds_for_organization(org_id)
end
ensure
Current.organization_id = nil
end
def organizations_with_pending_builds
Organizations::Organization.without_current_organization do
# make some query
end
end
end
a1f3c26a)