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. Also see https://gitlab.com/gitlab-org/gitlab/-/work_items/627524+ for prior discussion that led to this issue. ### About When a flow is enabled directly on a project, its service account is added as a Developer member of that project. That membership is what lets the flow act in the project, and what makes the flow trigger resolvable in mention and assign suggestions. A group inheritance enablement creates a single record on the group and no per-project records, so there is no membership for the inherited flow's service account in any descendant project. Without it, triggers fail (the service account has no access) and the bot cannot be found for mention or assign. We decided in https://gitlab.com/gitlab-org/gitlab/-/work_items/627524 to grant these memberships per-project rather than adding the service account once to the group and relying on inherited membership. The per-project approach is narrower, and it is what the next iteration (project opt-outs and overrides, https://gitlab.com/groups/gitlab-org/-/work_items/23437) will need. There is no natural way to grow a single group-wide membership into per-project memberships later, so we do it per-project now. The group inheritance record stays the single source of truth. We do not create per-project consumer records. ### Proposal We only sync `ProjectMember` rows for the service account across descendant projects. Async work must always check that the group enablement state is still as expected. So race conditions where 1. Group enablement happens 2. Fan out is queued/working but not complete 3. Group disablement happens are avoided. #### Add the service account Add the inheritance record's service account as a Developer (`::Gitlab::Access::DEVELOPER`, the same level project enablement uses) of descendant projects: - **On enablement** — async fan-out across all current descendant projects. - **On project creation** — when a project is created under a group that has an inheritance record for the item. - **On project transfer into** the hierarchy — when a project moves under a group that has an inheritance record. In all situations, but especially the async fan-out, we MUST make sure that we handle a situation where the member already exists idempotently - so it doesn't fail. There can be situations where the project already has the member (example https://gitlab.com/gitlab-org/gitlab/-/merge_requests/256297#note_3882147365). For the fan-out, add a new `Ai::Catalog::AddServiceAccountMembersToHierarchyWorker` to mirror the existing `Ai::Catalog::DeleteServiceAccountMembersFromHierarchyWorker`: walk the group's descendant projects, add the service account as Developer. Reuse the membership primitive already in `Ai::Catalog::ItemConsumers::CreateService#add_service_account_to_project` - this may need extraction into a shared service (can we have that method _and_ our method use `Ai::ServiceAccountMemberAddService` to turn that into our SSoT?). #### Remove the service account **On group disable** Reuse `Ai::Catalog::DeleteServiceAccountMembersFromHierarchyWorker`, which already walks the hierarchy and deletes via `Members::DestroyService`. However, [`#memberships`](https://gitlab.com/gitlab-org/gitlab/-/blob/3e605d51f550f99e398d2d66bd23a86248fcd41e/ee/app/workers/ai/catalog/delete_service_account_members_from_hierarchy_worker.rb#L56) currently operates from memberships within the top-level group - as its a destructive method we may want to future proof this and change it to operate on memberships from the group and its descendants only. For example, to: ```ruby def memberships ::ProjectMember.where(project: group.all_projects).with_user(service_account) end ``` **On project transfer out** of the hierarchy — see below. #### The "still needed here?" guard `DeleteServiceAccountMembersFromHierarchyWorker` skips a membership that is still needed, via `Ai::Catalog::ItemConsumer.exists_for_service_account_and_project_id?`. That method looks for a project-level record whose `parent_item_consumer` holds the service account. Under this design there are no per-project records, so an inheritance-granted membership would not be recognised as needed, and the worker could delete a membership that another active inheritance record still requires. Extend the guard so a membership is treated as needed when an active inheritance record on the project's group hierarchy grants it for that service account. The predicate must consider both the existing project-record case (unchanged) and the new inheritance case. #### Project transfer out of the hierarchy When a project moves out of its group hierarchy, the group service account is no longer authorised to act in it (it is a group-scoped service account being invoked outside the group), but the project's triggers travel with it. In this issue we: - Drop any service account memberships (look up inherited enabled consumers) from the transferred project. - Disable the now-orphaned associated triggers by setting `active: false`, keeping the rows but making them untriggerable. We should apply this cleanup to the existing group `direct` service account case too, not only inheritance records. Today a project moved out of its top-level group keeps triggers that silently fail because the group service account has no access outside the hierarchy; this issue tidies that up as part of the same transfer-out handling. **In scope:** dropping the service account and disabling the orphaned triggers on transfer out, for both inheritance and existing group `direct` records. **Out of scope (follow-up):** the UX for discovering and understanding disabled triggers after a move-out, so users see why triggers stopped rather than experiencing silent failures. To be a separate follow-up issue.