This issue is part of the AI Catalog Group Inheritance Epic https://gitlab.com/groups/gitlab-org/-/work_items/22487 see that epic for more context. ### About This is where a user can actually create a group inheritance record. It extends the existing "enable an item" mutation and its service so that enabling on a top-level group creates an inheritance record, with flow triggers if the item is a flow. It also handles the awkward case where an item is already enabled directly on projects underneath the group. Since this iteration has no concept of a project keeping its own settings, a group inheritance enablement takes over. Any existing project enablements for that item, and their triggers, are removed and replaced by the single group inheritance record. Because this is destructive, the mutation lets the caller find out first that project enablements would be replaced, so the frontend can warn before it happens. Finally, we reuse the service account that already exists for the item at the group level, rather than creating a new one, so the switch to inheritance does not churn service accounts or their memberships. ### Proposal #### Services ##### `ItemConsumers::CreateService` - Allow TLG groups to create an inheritance-type consumer record by accepting a new `consumer_kind` param. The service must consider this argument to be required for groups, but it can set it explicitly for projects. Since the column is `NOT NULL` with no default, a missing kind will fail loudly. - Service account is created if it doesn't already exist. It is added as developer member of the group. - Block a project from enable an item that it is already inheriting (assess if it's best for this to be a model validation). - Destroy any existing project enablements when TLG inheritance-type records is created (see below for more details) - The trigger arguments (`triggerTypes`, `triggerFilter`, and any current equivalent such as `triggerConditions`, confirm on master) are today rejected for group targets. For an inheritance create they are allowed, and produce a group-scoped trigger. ##### Memberships Another issue https://gitlab.com/gitlab-org/gitlab/-/work_items/629248 will handle sync'ing SA membership to the descendant projects. In this issue, we could either not do any SA membership at all (meaning, flows won't work yet), or add the SA as a developer member of the group temporarily slow flows work, and make a note in https://gitlab.com/gitlab-org/gitlab/-/work_items/629248 to change this. ##### Handling when project already has enabled the item See https://gitlab.com/gitlab-org/gitlab/-/work_items/600203#note_3779520856 for some earlier context. A TLG may already have 1000s of projects that have enabled the item. Enabling as an inheritance item will destroy those enablements. We want to: 1. Do the minimum needed within the transaction to have the inheriting group enablement fire instead of the project enablement. Possibilities: - Deleting potentially 1000s of records performantly - Clever scoping to remove duplicates (group enablement wins) https://gitlab.com/gitlab-org/gitlab/-/work_items/627518 2. Tidy up async (removing memberships - depending on outcome of https://gitlab.com/gitlab-org/gitlab/-/work_items/627524) ##### Handling when enabling on TLG and there is already a `direct` consumer record for the group. We want to reuse the existing Service Account that was created. We want to delete the `direct` group record, and create an `inheritance` one. We might be able to remove the validation in `ee/app/models/ai/catalog/item_consumer.rb` that allows both kinds to co-exist at group-level. ---------- ##### `ItemConsumers::DestroyService` To destroy inheritance-type consumer records, if needed. ---------- ##### `ItemConsumers::BulkCreateService` Should JustWork, but test the scenario that a bulk-selected project already inherits the item is reported without failing the whole batch. #### GraphQL mutations ##### Mutation: `AiCatalogItemConsumerCreate` The existing create mutation takes a `target` that is a project or a group. Today a group target creates the legacy direct enablement record. We add the notion of kind and the override handling. Add a `consumerKind` enum argument (a new `Types::Ai::Catalog::ItemConsumerKindEnum` with `DIRECT` and `INHERITANCE`), defaulting to `DIRECT`. - Argument defaults to `DIRECT`, keeps every existing caller working exactly as before. - `INHERITANCE` is only valid with a group target and only when the feature flag is on. #### Handling the client being able to "test" existing project consumers for the item before See proposal thread: https://gitlab.com/gitlab-org/gitlab/-/work_items/627517#note_3795521309 #### GraphQL types Note, follow https://gitlab.com/gitlab-org/gitlab/-/work_items/627520 closely as we'll need to implement data for the FE. Currently (draft) - Allow FE to know which group an inherited item enablement belongs to #### Audit events and metrics Has its own issue https://gitlab.com/gitlab-org/gitlab/-/work_items/627977: However, that issue could be picked up and done alongside this one if it's easier.