## Problem The virtual repository detail page's upstream table renders a per-row kebab menu, added in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/255796, with "Edit repository" (every row) and "Clear cache" (remote-source rows only). Both items act on the upstream repository, a different repository from the virtual one the page reads. The page never performs a read that returns a permission verdict for an upstream, so neither item can be gated today, and both render for every user. This is a known gap in the broader permission-gating effort. https://gitlab.com/gitlab-org/gitlab/-/issues/628427 gates the edit route, the list create dropdown, the list row kebab, the detail header, the connection test control, the detail kebab, and the create route, using the `permissionAllows(block, action)` seam in `ee/app/assets/javascripts/packages_and_registries/artifact_registry/graphql/utils/permissions.js`. That issue explicitly puts every virtual upstream row item out of scope, including this one: "Nothing rides a read for a resource the page does not resolve", so a row item whose subject is the sibling upstream repository has no verdict to read. The AR spec monolith/S15 (`docs/specs/monolith/S15-permission-gated-controls.md` in https://gitlab.com/gitlab-org/ops/artifact-registry, Approved) records the binding explicitly: the row's "Edit repository" reads the upstream's own `update_repository` verdict, and the row's "Clear cache" reads the upstream's own `delete_artifact` verdict. Neither may be inferred from the virtual repository's own verdicts. A third row item, **Remove repository**, was added by https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257151 (open as of writing, `monolith/S07` Phase 3) and, like the other two, renders ungated for every row. Unlike the other two, its subject is the *virtual* repository, not the upstream: it dissociates the row's upstream from the page's own repository (`artifactRegistryUpstreamRepositoryDissociate`, called with the virtual repository's own `name`/`format`). The S15 spec's permission table binds it explicitly: > `delete_repository_upstream` | Repository scope gates the Remove repository item on the upstream row, the one item on that kebab whose subject is the page's own repository, when it ships. **Gates on arrival.** and lists it under "Surfaces gated on arrival" as answered by the repository detail read the page already performs, same as `update_repository` and `delete_artifact` already are. So, unlike Edit repository and Clear cache, gating Remove repository needs no new AR read and is not blocked on artifact-registry#1174: the action already exists server-side on `Types::PermissionTypes::ArtifactRegistry::Repository` (`ee/app/graphql/types/permission_types/artifact_registry/repository.rb`) and its JS constant already exists (`REPOSITORY_PERMISSION_DELETE_REPOSITORY_UPSTREAM` in `constants.js`); the query just doesn't select it yet, and `upstream_repository_actions.vue` doesn't gate on it yet. ## Proposal Once https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1174 ships, adding the existing `include_permissions` opt-in to the upstream-association list read and a `RepositoryPermissions` object on each row's `upstream_repository` summary, wire it through the monolith: 1. `ee/lib/artifact_registry/client.rb`: give `#upstream_repositories` an `include_permissions:` keyword and parse each row's permissions block, the same way `#repository` and `#repositories` already do. 2. `ee/lib/artifact_registry/upstream_repository_summary.rb`: carry the verdict block. 3. `ee/app/graphql/types/artifact_registry/upstream_repository_summary_type.rb`: add a `user_permissions` field typed `Types::PermissionTypes::ArtifactRegistry::Repository` (GraphQL name `ArtifactRegistryRepositoryPermissions`), mirroring `repository_type.rb`. 4. The resolver serving `upstreamRepositories` requests the verdicts. 5. Frontend: add the verdict fields to the upstream selection in `get_repository_detail.query.graphql`, and in `repositories/detail/upstream_repository_actions.vue` gate "Edit repository" on `updateRepository` and "Clear cache" on `deleteArtifact` through `permissionAllows`, rendering no kebab toggle when both are denied. This matches the rule the shipped `row_actions_menu.vue` and `repository_actions.vue` already follow. AR#1174 reuses the parameter and schema the monolith already consumes for other reads, so no new action set or field shape is needed on the monolith side. Separately, and **not blocked by AR#1174**, gate "Remove repository": 6. `get_repository_detail.query.graphql`: add `deleteRepositoryUpstream` to the repository's existing `userPermissions` selection (alongside `updateRepository`, `deleteRepository`, `deleteArtifact`). 7. `upstream_repository_actions.vue` already receives the page's `repository` object as a prop (added by !257151 for the dissociate mutation's `name`/`format`). Gate the Remove repository item on `permissionAllows(this.repository.userPermissions, REPOSITORY_PERMISSION_DELETE_REPOSITORY_UPSTREAM)`. 8. Once both this step and the AR#1174-dependent step above have landed, the row's kebab should render no toggle when all three items (Edit repository, Clear cache, Remove repository) are denied, consistent with the empty-menu rule the other gated kebabs follow. ## Out of scope Nothing about this row's kebab is out of scope any more. All three items — Edit repository, Clear cache, and Remove repository — need gating; only the first two are blocked on AR#1174, because only they ask about a resource (the upstream) the page never reads. Remove repository asks about the page's own repository and rides the existing detail read, so it ships independently. ## Blocked by - https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1174 ("Embed upstream repository verdicts in listUpstreamRepositories"). Open, unassigned, no milestone as of writing. Blocks "Edit repository" and "Clear cache" only — **not** "Remove repository". ## Acceptance criteria - [x] `ArtifactRegistry::Client#upstream_repositories` accepts `include_permissions:` and parses the returned verdict block per row. - [x] `ArtifactRegistry::UpstreamRepositorySummary` carries the verdict block. - [x] `Types::ArtifactRegistry::UpstreamRepositorySummaryType` exposes `user_permissions` typed `Types::PermissionTypes::ArtifactRegistry::Repository`. - [x] The `upstreamRepositories` resolver requests verdicts via the new keyword. - [x] `get_repository_detail.query.graphql` selects the new verdict fields on the upstream, and separately selects `deleteRepositoryUpstream` on the page's own repository `userPermissions`. - [x] `upstream_repository_actions.vue` gates "Edit repository" on `updateRepository` and "Clear cache" on `deleteArtifact` via `permissionAllows`. - [x] `upstream_repository_actions.vue` gates "Remove repository" on `deleteRepositoryUpstream` (the page's own repository verdict) via `permissionAllows`, independently of the AR#1174 work above. - [x] The row's kebab renders no toggle when all applicable items are denied. - [x] Behavior verified behind the `artifact_registry_ui` feature flag.