Define CI Catalog and CI Catalog Resource permission scheme
Problem
We're in the process of defining CI Namespace Catalog permissions in the code, and we need to make sure we all agree on how that is going to be done.
What is already done?
-
ci_private_catalog
licensed feature is defined inEE::GitlabSubscriptions::Features
-
add_catalog_resource
is defined inProjectPolicy
. Only owners can add a catalog resource -
EE::Ci::Catalog::ResourcesHelper#can_view_private_catalog?
checks the licensed feature and is used by the frontend andCi::Catalog::ResourcesController
to control access to the namespace catalog
Proposal
- Rename
ci_private_catalog
toci_namespace_catalog
- Add
read_namespace_catalog
toNamespacePolicy
. Ensure that it checks theci_private_catalog_beta
feature flag, theci_namespace_catalog
licensed feature, and that the user has Developer+ permissions on the namesapce - Update
add_catalog_resource
to check thatci_namespace_catalog
is available. Should it also check a feature flag? Which one? - Update
EE::Ci::Catalog::ResourcesHelper#can_view_private_catalog?
to only checkread_namespace_catalog
soread_namespace_catalog
can be the SSOT -
read_namespace_catalog
will be used to control access to the new GraphQL fields defined in #393567 (closed) -
add_catalog_resource
will be used to control access to the new GraphQL mutation defined in #387065 (closed) - Anything else?
Acceptance criteria
- Namespaces not in Ultimate plans should not have access to a private catalog, nor being able to mark projects as catalog resources.
- Namespaces not in Ultimate plans should be able to still use
include:component
feature.
Considerations
Eventually when we have the public catalog, publishing catalog resources will be available to everyone and some of the features like "mark this project as a catalog resource", catalog checks when creating new releases, list catalog resources, etc. will eventually be moved to GitLab Core to satisfy the Public Catalog use-cases.
Edited by Avielle Wolfe