Raise the permissions of the group-level APIs to owner
🚨 Please remove confidential of this issue when https://gitlab.com/gitlab-org/gitlab/-/issues/364441 gets released! In https://gitlab.com/gitlab-org/gitlab/-/issues/364441 we identified a discrepancy between the UI & the API Group Owners / administrators permission for package and registries settings. ## Context Currently, the docs show that maintainers should have the ability to change these settings: https://docs.gitlab.com/ee/user/permissions.html#group-members-permissions We [recently updated the graphql/api permissions](https://gitlab.com/gitlab-org/gitlab/-/issues/350682) to be maintainer from developer to conform with the frontend. It looks like we got mixed up somewhere in https://gitlab.com/gitlab-org/gitlab/-/issues/350682 and https://gitlab.com/gitlab-org/gitlab/-/issues/322055 and the UI has required owner all along. Access to the settings tab, & therefore Packages & Registry settings on the left side is [available](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/sidebars/groups/menus/settings_menu.rb#L9) only for group owners (they have `:admin_group` set on their [group policy](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/policies/group_policy.rb#L185)) and the same [check](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/controllers/groups/settings/packages_and_registries_controller.rb#L7) is made if the user tries to visit the URL directly. So maintainers don't have access to this UI. ## Proposed solution Raise the permissions of the group-level APIs to `owner`. The [note warning of the deprecation in GraphQL](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96387) should be removed. Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/364441 ## Breaking change tasks ### Affected Topology This affects Self-Managed users of GitLab. ### Affected Tier All tiers are affected. * Free * Premium * Ultimate ### Checklists **Labels** - [ ] This issue is labeled ~deprecation, and with the relevant `~devops::`, `~group::`, and `~Category:` labels. - [x] This issue is labeled ~"breaking change" if the removal of the deprecated item will be a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes). **Timeline** Please add links to the relevant merge requests. - As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: `14.8, 14.9, 14.10, 15.0` – `14.8` is the third milestone preceding the major release): - [x] A [deprecation announcement entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-a-deprecation-announcement) has been created so the deprecation will appear in release posts and on the [general deprecation page](https://docs.gitlab.com/ee/update/deprecations). - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108055 - [ ] Documentation has been updated to mark the feature as [deprecated](https://docs.gitlab.com/ee/development/documentation/versions.html#deprecations-and-removals). - [x] On or before the major milestone: A [removal entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#removals) has been created so the removal will appear on the [removals by milestones](https://docs.gitlab.com/ee/update/removals) page and be announced in the release post. - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108055 - On the major milestone: - [ ] The deprecated item has been removed. - [ ] If the removal of the deprecated item is a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes), the merge request is labeled ~"breaking change". **Mentions** - [x] Your stage's stable counterparts have been `@mentioned` on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager: @heather. - To see who the stable counterparts are for a product team visit [product categories](https://about.gitlab.com/handbook/product/categories/) - If there is no stable counterpart listed for Sales/CS please mention @timtams - If there is no stable counterpart listed for Support please mention @gitlab-com/support/managers - If there is no stable counterpart listed for Marketing please mention `@cfoster3` - [x] Your GPM @jreporter has been `@mentioned` so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change. ### Deprecation Milestone 15.8 ### Planned Removal Milestone 16.0
issue