Add read_package custom ability

What does this MR do and why?

This is MR 1 of 3. It adds a read_package custom ability for custom roles (Ultimate). It lets a custom role view packages without the allow_guest_plus_roles_to_pull_packages feature flag.

Why we need it

• The allow_guest_plus_roles_to_pull_packages flag lets Guest (and Planner) users pull packages from private projects.
• The flag is on for one root group on GitLab.com.
• The authorization team needs the flag out of the policy files.
• On #336622, the authorization team and product chose a custom ability over a group setting.
• The group setting MR, !257653 (closed), was closed.

Changes

• New ability: ee/config/custom_abilities/read_package.yml. Title is "View packages". It is a group and project ability.
• Default grant: Reporter, Security Manager, Developer, Maintainer, and Owner get it. These are access levels 20, 25, 30, 40, and 50.
• No billable seat: skip_seat_consumption: true. A Guest with only this ability does not use a seat. This matches read_code and read_virtual_registry, and today's flag behavior.
• No policy changes: EE project and group policies already enable the permissions of every custom ability.
• No migration: abilities live in member_roles.permissions.
• Hidden until MR 3: wip: true keeps the ability out of the loaded set, so it isn't in the custom role docs, GraphQL enums, or the REST API yet. Specs load wip abilities by default. MR 3 removes wip: true and regenerates those files.
• Spec: ee/spec/requests/custom_roles/read_package/request_spec.rb. With the flag off, a Guest with the custom role can list and show packages in a private project through the REST API. This works as a project member and as a group member. A plain Guest gets 403. All 5 examples pass locally.

Behavior change

None by default. Only custom roles that turn on read_package change anything.

What is not in this MR

• MR 2: makes the cross-project package finders honor the custom ability. This covers Packages::FinderHelper, Packages::Npm::PackagesForUserFinder, and Packages::ProjectsFinder. It fixes group- and instance-level package endpoints.
• MR 3: Support helps the one customer set up a custom role. Then we delete the flag.

Until MR 2 lands, group- and instance-level package endpoints may not show packages to a Guest who has only this ability.

References

• #517068
• #336622
• Flag rollout: #512210

Screenshots or screen recordings

Not applicable. There are no UI changes. The custom role UI lists abilities automatically.

How to set up and validate locally

1. Enable the custom roles license.
2. In a Rails console, disable the flag:

   Feature.disable(:allow_guest_plus_roles_to_pull_packages)

3. In a top-level group, create a custom role based on Guest. Turn on "View packages".
4. Assign the role to a user on a private project that has a package.
5. As that user, call GET /api/v4/projects/:id/packages. It returns 200.
6. As a plain Guest, call the same endpoint. It returns 403.

Database changes

None.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code