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 https://gitlab.com/gitlab-org/gitlab/-/work_items/627512 added a single lookup for "which triggers apply to this project", combining a project's own triggers with the ones it inherits from its top-level group. This issue puts that lookup to work everywhere triggers actually fire, so an inherited flow trigger runs in a descendant project exactly like a project's own trigger would. There are several places that react to events (a pipeline finishing, a merge request event, an assignment, a mention) and look up which triggers to run. Each needs to use the shared lookup instead of only checking the project's own triggers. The flow still runs in the project where the event happened, using the service account stored on the inheriting record. One related surface is the participant list used for mention and assign suggestions. It needs to know a service account responds to events in a project when that comes from an inherited trigger, not just a project trigger. With the feature flag off, every one of these paths behaves exactly as it does today. Note there is a dependency on the service account membership issue. Until that is resolved, an inherited flow's service account may not be a member of descendant projects, which affects whether mention and assign can resolve it. Firing still works for event-based triggers that do not depend on membership. ### Proposal We add an encapsulated lookup so that other parts of the codebase can use a single place to answer "which triggers apply to this project", which returns the project's own triggers plus any triggers inherited from its top-level group. In all places that refer to project triggers, we wire the look up. #### Encapsulate the trigger lookup It answers "which triggers apply to this project for this event", combining the project's own triggers with triggers inherited from its top-level group. It would be feature-flagged, so with the flag off it returns exactly today's result. Propose a class method for this: ```ruby FlowTrigger.applicable_to_project(project, triggered_on:) ``` #### Change all places that need to look up inherited triggers Everywhere that currently does `project.ai_flow_triggers.active.triggered_on(...)` to decide what to run will be updated to use our class method above. Confirm the exact call sites on master before editing, as trigger event system may have been reworked recently. As of the current master the firing paths are: 1. `Ai::FlowTriggers::EventTriggerService` Pipeline hook events. 2. `Ai::CloudEventsFlowTriggerWorker` Shared base for the newer event workers. 3. `EE::IssuableBaseService` assign / assign_reviewer events. 4. `EE::Notes::PostProcessService` mention events. Note there is a second lookup in this file (something like `mention_trigger_exists_for?`), check whether it also needs the inherited set or is only about the project's own triggers. #### Participant list (mention / assign suggestions) `EE::Users::ParticipableService` builds the list of service accounts and the events they respond to, so the UI can suggest them for mention/assign. On master it does roughly: ```ruby ::Ai::FlowTrigger.active.by_service_accounts(user_ids) .for_projects(participation_object_project_ids).include_parent_item_consumer ``` This only finds project triggers. We need to also include inherited triggers whose top-level group is the top-level group of any of these projects. #### 4. `by_service_accounts` needs a third branch Today this scope matches triggers by the trigger's `user_id`, and by the service account on the trigger's parent item consumer. Inheriting triggers hold the service account on the inheriting record itself (not a parent), so add a branch that also matches on the inheriting consumer's own service account. Confirm the exact current shape before editing, then extend the union it already builds. ### :robot: Agent planning Please see below for the original agent plan (note this plan may not reflect latest plan): <details> <summary>Click to see thinking</summary> #### 3. The trigger lookup This is the key mechanism later issues wire into. It answers "which triggers apply to this project for this event", combining the project's own triggers with triggers inherited from its top-level group. It is feature-flagged, so with the flag off it returns exactly today's result. ```ruby # Only top-level group inheriting is supported this iteration. Subgroup # inheriting is a separate future task. scope :for_project_root_group, ->(project) { next none unless project.root_ancestor.is_a?(Group) joins(:ai_catalog_item_consumer) .where(group_id: project.root_ancestor.id) .where(ai_catalog_item_consumers: { consumer_kind: Ai::Catalog::ItemConsumer.consumer_kinds[:inheriting] }) .select(arel_table[Arel.star]) # keep columns aligned for from_union } def self.applicable_to_project(project, triggered_on:, by_service_accounts: nil) project_triggers = project.ai_flow_triggers.active.triggered_on(triggered_on) project_triggers = project_triggers.by_service_accounts(by_service_accounts) if by_service_accounts return project_triggers unless Feature.enabled?(:ai_catalog_group_inherited_consumers, project.root_ancestor) group_triggers = for_project_root_group(project).active.triggered_on(triggered_on) group_triggers = group_triggers.by_service_accounts(by_service_accounts) if by_service_accounts from_union([project_triggers, group_triggers]) end ``` Notes: - The `select(arel_table[Arel.star])` matters: `for_project_root_group` joins another table, and `from_union` needs both relations to select the same columns (just `ai_flow_triggers.*`), or the union fails. - `for_project_root_group` filters on `consumer_kind = inheriting` via the join, so it never picks up a future group-level `direct` record. - A plural variant, e.g. `for_project_ids_root_groups(project_ids)`, is needed by the participable service (issue 5). It should return triggers whose `group_id` is the top-level group of any of the given projects, filtered to inheriting the same way. Deriving each project's top-level group in SQL can use the namespaces `traversal_ids[1]` (the root id), similar to existing scopes, avoiding an N+1. #### 4. `by_service_accounts` needs a third branch Today this scope matches triggers by the trigger's `user_id`, and by the service account on the trigger's parent item consumer. Inheriting triggers hold the service account on the inheriting record itself (not a parent), so add a branch that also matches on the inheriting consumer's own service account. Confirm the exact current shape before editing, then extend the union it already builds. #### The change in one line Everywhere that currently does `project.ai_flow_triggers.active.triggered_on(...)` to decide what to run, call `Ai::FlowTrigger.applicable_to_project(project, triggered_on:, by_service_accounts:)` instead (added in the models issue). That method returns the project's own active triggers plus, when the flag is on, active triggers inherited from the project's top-level group. Confirm the exact call sites on master before editing, the trigger event system has been reworked recently. As of the current master the firing paths are: 1. **`Ai::FlowTriggers::EventTriggerService`** (called from `EE::Ci::Pipelines::HookService`) — pipeline hook events. Currently `project.ai_flow_triggers.active.triggered_on(event)`. 2. **`Ai::CloudEventsFlowTriggerWorker`** (concern, in `ee/app/workers/concerns/ai/cloud_events_flow_trigger_worker.rb`) — this is the shared base for the newer event workers (merge request ready/created/approved/merged/conflict, work item created/status-changed). It has a single `execute_flow_triggers` doing `container.ai_flow_triggers.active.triggered_on(event_type)`. Updating this one method covers all the workers that include the concern, which is the big win. 3. **`EE::IssuableBaseService`** — assign / assign_reviewer events. Currently `project.ai_flow_triggers.active.triggered_on(event_type).by_service_accounts(users)`. 4. **`EE::Notes::PostProcessService`** — mention events. Currently `note.project.ai_flow_triggers.active.triggered_on(:mention).by_service_accounts(...)`. Note there is a second lookup in this file (something like `mention_trigger_exists_for?`), check whether it also needs the inherited set or is only about the project's own triggers. For each, swap to `applicable_to_project`, passing `by_service_accounts:` where the current code filters by service accounts. The `container`/`project` argument stays whatever the event's project is (for the CloudEvents concern the container is the project the event occurred in). #### Participant list (mention / assign suggestions) `EE::Users::ParticipableService` builds the list of service accounts and the events they respond to, so the UI can suggest them for mention/assign. On master it does roughly: ```ruby ::Ai::FlowTrigger.active.by_service_accounts(user_ids) .for_projects(participation_object_project_ids).include_parent_item_consumer ``` This only finds project triggers. We need to also include inherited triggers whose top-level group is the top-level group of any of these projects. Use the plural root-group scope added in the models issue (`for_project_ids_root_groups`) and union it in, gated by the feature flag (`ai_catalog_group_inherited_consumers`, actor: the participation object's root ancestor): ```ruby def relevant_flow_triggers_for(service_accounts) base = ::Ai::FlowTrigger.active.by_service_accounts(service_accounts) project_triggers = base.for_projects(participation_object_project_ids) return project_triggers unless Feature.enabled?(:ai_catalog_group_inherited_consumers, participation_object.root_ancestor) root_group_triggers = base.for_project_ids_root_groups(participation_object_project_ids) ::Ai::FlowTrigger.from_union([project_triggers, root_group_triggers]) end ``` Confirm the exact current method and the `by_service_accounts` behaviour (the models issue adds a branch so it also matches an inheriting consumer's own service account, which this relies on). Also sanity-check the autocomplete preload (`EE::Autocomplete::UsersFinder` preloads `:ai_flow_triggers` and `:child_item_consumers_flow_triggers`) for N+1, though it is a preload and does not change correctness. #### Out of scope for this issue - `Ai::DailyFlowOnPushWorker` builds a synthetic trigger from a consumer it looks up by flow reference; it is a foundational-flow path and does not read persisted triggers, so nothing to change here. - `Types::Users::DuoStatusType` shows a user's trigger-event badges from user-based and parent-consumer associations; it will not reflect inherited triggers. This is a cosmetic gap noted as a follow-up, not part of this issue. #### Testing - For each firing path, a spec that an inherited group trigger runs in a descendant project for the relevant event, and that with the flag off only the project's own triggers run. - Participable service spec: an inherited trigger's service account shows the right events for a project under the same top-level group; flag off falls back to project-only. - Confirm no double-firing in the normal case. If the services issue leaves a window where both a project direct enablement and an inheriting record can exist for the same item, decide here whether the lookup should dedupe by item (project wins) or whether that window is acceptable. Cross-link the services issue. </details>