Refinement planning: Project maintainers to directly enable AI Catalog items (without group owner)

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

About

This issue is part of epic gitlab-org#20743 see that epic for more context.

• About
• Success criteria
• DRAFT High-level technical
• Behaviour matrix
  • Notes
  • Questions

Success criteria

Modified from gitlab-org#20743.

• Users can create triggers for agents and flows without requiring top-level group ownership
• Users can enable agents in their projects without requiring top-level group ownership
• Users can enable flows in their projects without requiring top-level group ownership
• Documentation updated

DRAFT High-level technical

Note, feature still in discussion, these are quick assumptions:

• Remove the ability for group owners to enable items, as it would be functionally redundant
• Allow project maintainers+ to always enable items directly (no need to factor presence of group enablement)
• Backend continues to create top-level group SAs, but can create them on project enablement directly (if not already created)
• ? Backend continues to create item consumers for groups, but functionally hidden from user

Behaviour matrix

Enabled from	Item scope	Enabling in	First pass	Second pass
Global (Explore)	Private	Managing project	Modal w/ group/project pre-selected/immutable, user clicks enable	Removing the modal and getting the button to do all the work was proposed by @michaelmoyers, but that conflicts with @florie's proposal
Global (Explore)	Public	Any project user is maintainer of	Modal w/ project selection list, user selects project and clicks enable	None
Project namespace	Private	Current (managing) project	"Enable" button, opens modal w/ project pre-selected/immutable, user clicks enable	Same as the first row of this table
Project namespace	Public	Current project or other project	"Enable" button, opens modal w/ project select list (projects user is maintainer of), user selects and clicks enable. Button remains visible after enabling.	Same (modal needed for project selection). Toast with link shown if enabled in a different project.

Notes

• Private items are always an "enable-and-forget": show active "Enable" unless it is already so, then disable the button.
• Public items can be enabled in multiple projects, so a modal with a project selection list is always needed since the user must choose which project. @michaelmoyers has proposed we support multiple project selection as well, but likely not on the radar for this iteration.
• Non-maintainers always see the Enable button, but the modal shows disabled controls and a banner nudging them to contact their project maintainer (per @fguibert's proposal).
• Group-level Automate page becomes read-only (first pass: disable button hidden, second pass: shows items enabled by descendant projects).

Questions

• What will roles higher than maintainer see in the project dropdown? Will a TLG owner see all projects that are in their TLG and sub-groups?