## Problem REST and GraphQL resolve `Current.organization` from the request (the `X-GitLab-Organization-ID` header, else the user's `organization_id`, else the default organization), not from the group or project being acted on (`lib/gitlab/current/organization.rb`, `lib/api/helpers.rb#set_current_organization`). After a top-level group moves into a non-default organization, its users are still in the default organization, so endpoints that use `Current.organization` as a filter, default, or consistency check break or write the wrong `organization_id`. Example: creating a subgroup under a moved top-level group returns `404 Group Not Found` unless `organization_id` is passed explicitly. ```shell curl -X POST -H "PRIVATE-TOKEN: $TOKEN" \ --data "name=sub&path=sub&parent_id=<moved TLG id>" \ https://gitlab.com/api/v4/groups # {"message":"404 Group Not Found"} # Works: curl -X POST -H "PRIVATE-TOKEN: $TOKEN" \ --data "name=sub&path=sub&parent_id=<moved TLG id>&organization_id=<new org id>" \ https://gitlab.com/api/v4/groups ``` <details> <summary> Why \`POST /groups\` fails </summary> `organization_id` defaults to `Current.organization.id` (`lib/api/groups.rb:329`) and the parent lookup is scoped with `Group.in_organization` (`lib/api/groups.rb:343`). Removing the scoping alone is not enough: `Groups::CreateService#set_organization` prefers `params[:organization_id]`, and `matches_parent_organization?` (`app/services/groups/create_service.rb:143`) would then reject the request. The default should not apply when `parent_id` is given. </details> The web UI sends `X-GitLab-Organization-ID` from `gon.current_organization` (`app/assets/javascripts/lib/graphql.js`), which comes from the page URL. Moved-group pages send the new organization; `/dashboard`, `/explore`, `/projects/new`, `/groups/new`, user settings, and admin send the default one. API, IDE, and CLI clients send no header. The same call can behave differently depending on its origin. ### Affected tokens Whether a request breaks depends on whose token it uses, because the token's user decides the fallback organization. For the full breakdown by token type, see the [token breakdown comment](https://gitlab.com/gitlab-org/gitlab/-/work_items/635512#note_4094277865). - Tokens of human users break: personal access tokens, OAuth tokens, impersonation tokens, feed and static object tokens, pipeline trigger tokens, and CI job tokens, which usually run as the human user who started the pipeline. Instance service account tokens break the same way. - Group and project access tokens, and group service account tokens, break only if they were created before the move. Their bot users stay in the old organization until https://gitlab.com/gitlab-org/gitlab/-/work_items/635597 moves them with the group. - Deploy tokens, runner authentication tokens, and cluster agent tokens resolve from their project, group, runner, or agent, and keep working. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/265222 resolves REST requests from the group or project the route acts on, when no header is sent, so the token type no longer matters for the routes it covers. ## Audit results Read-only audit of `Current.organization` and organization scoping reachable from REST and GraphQL. Items marked _unverified_ were not fully traced. The breakages fall into three categories. ### Severity Severity is based on what breaks. | Severity | What breaks | |----------|-------------| | **S1: Wrong data** | A record is saved with the wrong organization, or crosses an organization boundary. It stays wrong after the code fix and needs a data fix. | | **S2: Action blocked** | The request fails with an error, so the user can't do it. | | **S3: Wrong results** | The request succeeds, but returns incomplete or wrong data, or a side effect silently doesn't happen. | | **S4: Cosmetic** | It works, but the UI offers options that then fail, or a suggestion is missing. | - Breakages that only instance administrators can trigger drop one level, to no lower than S4. - Breakages behind a feature flag that is off by default drop one level, to no lower than S4. ### Category 1: records created under a parent (`POST`, `PUT`, and mutations) The service has, or could look up, the parent, so it should take the organization from it. Callers pass an organization only when the service cannot derive it. | Breakage | Severity | MR | Status | Reason | Fix | |----------|----------|----|--------|--------|-----| | `POST /groups` with `parent_id` | S2 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/266008 | ~"workflow::complete" | `lib/api/groups.rb` defaults `organization_id` to `Current.organization.id`, overriding the parent | Apply the default only without `parent_id`, so `Groups::CreateService#set_organization` uses the parent group's organization | | `POST /groups/import` with `parent_id` | S2 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/266008 | ~"workflow::complete" | `lib/api/group_import.rb` defaults `organization_id` to `Current.organization.id` | Same as `POST /groups` | | `POST /import/github` | S2 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/266043 | ~"workflow::complete" | `lib/api/import_github.rb` merges `organization_id: Current.organization.id`, so `target_namespace` is looked up in the request's organization | Stop passing the request's organization. The target namespace carries its own | | `POST /projects/:id/deploy_keys`, project deploy key form | S1 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/266034 | ~"workflow::complete" | Callers pass `organization: Current.organization` | `DeployKeys::CreateService#execute(project:)` uses the project's organization | | Service account tokens (group and project) | S1 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/266035 | ~"workflow::complete" | Callers pass `organization_id: Current.organization.id` | `PersonalAccessTokens::CreateService` defaults to the service account's organization | | EE: GraphQL `aiCatalogMcpServerUpdate` | S2 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/264788 | ~"workflow::complete" | Authorizes against `context[:current_organization]` (`ee/app/graphql/mutations/ai/catalog/mcp_server/update.rb:59`) | Authorize against the server's own organization | | `POST /offline_exports` | S2 (flag `offline_transfer_exports` off by default, S1 base) | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/266730 | ~"workflow::complete" | `lib/api/offline_transfers.rb` passes `Current.organization.id` | Take the organization from the exported groups and projects in `entities` | | GraphQL `personalAccessTokenCreate` and `POST /user/personal_access_tokens` with granular scopes on a moved group or project | S2 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/267314 | ~"workflow::complete" | The token gets `Current.organization`, and `Authz::GranularScope#organization_match` requires each scoped namespace to be in the token's organization | Take the token's organization from the scoped namespaces, and reject scopes in different organizations | Admin-created tokens for another user (`POST /users/:user_id/personal_access_tokens`, `POST /users/:user_id/impersonation_tokens`, admin impersonation tokens page) are tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/637868, because only administrators can trigger them. GraphQL `createCustomDashboard` with `namespaceId` is tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/638212 with ~"group::platform insights", because the feature is behind a flag that is off by default and has no create flow in the UI. ### Category 2: filters and consistency checks (`GET` and queries) These do not create anything. They use the request's organization as a filter or a check. A non-isolated organization resolves to User or Nil context, the same as no organization ([Request Context](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/organization/contexts/)), and org-scoped finders apply an organization filter only for an isolated organization ([ADR 016: Query scoping](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/organization/decisions/016_user_context/#query-scoping)). Removing the filter covers non-isolated organizations. Isolated organizations keep a filter. | Breakage | Severity | MR | Status | Reason | Fix | |----------|----------|----|--------|--------|-----| | `GET /projects`, `GET /users/:id/projects`, GraphQL `Group.sharedProjects` | S3 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/266013 | ~"workflow::complete" | `ProjectsFinder` filters by `Current.organization` | Remove the filter | | `GET /projects/:id/events`, `GET /events`, `GET /users/:id/events` | S3 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/266013 | ~"workflow::complete" | `EventsFinder#by_organization` filters by `Current.organization` | Remove the filter | | GraphQL `aiCatalogItem` | S3 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/267214 | ~"workflow::complete" | Requires the item's organization to equal the request's | Allow items in the same data context: the same organization, or both non-isolated | | `GET /projects/:id/transfer_locations`, `GET /groups/:id/transfer_locations` | S3 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/264769 | ~"workflow::complete" | Filter by the request's organization, or not at all, but transfers must stay in the resource's organization | Exact match on the resource's organization | | GraphQL `User.groups` | S3 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/267324 | ~"workflow::complete" | Filtered by the request's organization, so a moved group is missing from its members' own lists, such as the fine-grained token group picker. `frecentGroups` filters only with `scopeToOrganization: true`, which only the flagged custom dashboards page passes | Filter only when access comes through the organization owner role, and for `soloOwned` | ### Category 3: no parent, or a deliberate choice These have no parent resource to take the organization from, or the right organization depends on a decision rather than on the data. They need a product or Organization team decision, or a targeted fix, before they can be resolved. | Breakage | Severity | MR | Status | Reason | Fix | |----------|----------|----|--------|--------|-----| | Duo Chat threads: GraphQL `aiAction`, `aiMessages`, `POST /chat/completions` (`Gitlab::Llm::ThreadEnsurer`) | S2 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/264783 | Asked ~"group::duo chat" for guidance - https://gitlab.com/gitlab-org/gitlab/-/work_items/635512#note_4146566032 | User-scoped records with no parent resource | Product decision on which organization threads belong to | | EE: Duo Code Review bot in user autocomplete | S4 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/264796 | ~"workflow::complete" | Looks up the bot in `current_user.organization_id` | Look up in the project's organization. Close to category 1 | Forks and group and project sharing links across organizations are tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/637898. The Duo CLI setting check in `POST /ai/duo_workflows/workflows` is tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/637928, because only an instance administrator turning off Duo CLI is affected. ### Working as intended Creating a top-level group, `aiCatalogMcpServerCreate`, and `createCustomDashboard` without `namespaceId` have no parent resource, so nothing in the request names an organization other than the request's own. They use the header if one is sent, then the user's home organization. To create one in another organization, pass `organizationId` or the `X-GitLab-Organization-ID` header. ### Isolated organizations If the new organization is isolated, sending its ID in the header hides default-org records: the group's users, their personal namespaces, and cross-org forks and shares (`app/models/concerns/use_sql_function_for_primary_key_lookups.rb`, data isolation `:arel` strategy). The header workaround then causes broader breakage. When a user is deleted, their records in a moved group's projects are reassigned to the default organization's ghost user. This is tracked in https://gitlab.com/gitlab-org/gitlab/-/work_items/638190. ### Checked and not affected `POST /projects`, project forks (the fork itself; fork networks can span organizations, see https://gitlab.com/gitlab-org/gitlab/-/work_items/637898), Bitbucket and Bitbucket Server imports (organization from namespace); bulk and offline imports (organization from destination group); project snippets, notes, and search (organization filter applies only under isolation); invitations (skip the global organization setup). No `organization_id` column defaults remain in `db/structure.sql`. ## Proposal 1. Derive the organization from the resource when the request names one (`parent_id`, `target_namespace`, `:id`), and fall back to `Current.organization` only when no resource is given. 2. Remove `Current.organization` filters from finders where the resource already determines the organization (`GET /projects`, events, user groups, GitHub import target namespace). 3. Use the resource's organization for records created under a group or project (service account tokens, deploy keys, exports). 4. Split fixes into separate issues per endpoint as needed. ## Merge requests ### Category 1: records created under a parent ```glql display: table fields: title, author, state, reviewers, labels("workflow::*"), updated query: type = MergeRequest and project = "gitlab-org/gitlab" and id in (266008, 266043, 266034, 266035, 264788, 266730, 267314) ``` ### Category 2: filters and consistency checks ```glql display: table fields: title, author, state, reviewers, labels("workflow::*"), updated query: type = MergeRequest and project = "gitlab-org/gitlab" and id in (266013, 267214, 267353, 264769, 267324) ``` ### Category 3: no parent, or a deliberate choice ```glql display: table fields: title, author, state, reviewers, labels("workflow::*"), updated query: type = MergeRequest and project = "gitlab-org/gitlab" and id in (264783, 264796) ```