Pass work item status name to flow trigger filters

What does this MR do and why?

Problem

Flow triggers for Work item > Status changed fired on every status transition, regardless of any filter the user configured.

Users could set a filter rule on the status through the API, and the API accepted and stored it, but the trigger then stopped firing at all.

The cause was in the Sidekiq worker, ExecuteWorkItemStatusChangedWorkflowTriggersWorker. It only passed { 'action' => 'status_changed' } into Ai::FlowTriggers::FilterEvaluator, so a status rule always compared against nil and never matched.

Fix

This MR fixes the data flow so a status.name rule can match. With it, a trigger can be scoped to specific statuses through the API today. The trigger form gains a matching control in the stacked frontend MR.

Changes

• Worker concern hook: Ai::CloudEventsFlowTriggerWorker now passes the cloud event through execute_flow_triggers, and merges in a new overridable hook, filter_data_extras(cloud_event), which returns {} by default.
• Status data wiring: ExecuteWorkItemStatusChangedWorkflowTriggersWorker overrides filter_data_extras to return { 'status' => { 'name' => <new status name> } }, taken from the cloud event payload.
  • The WorkItems::StatusChangedEvent already carried status.name, so this only wires up data that was already available.
• New allowed filter field: Ai::FlowTrigger::ALLOWED_FILTER_FIELDS gains a work_item entry allowing the fields action and status.name.
  • Field validation runs unconditionally, so this entry takes effect on merge. See "Before merging" below.
• Duplicate validation fix: Blank action values for work_item filters were reported twice once both validators applied. The presence check now skips action rules that filter_action_values_allowed already covers.

Filter shape

The expected filter shape adds a status.name rule alongside the existing action rule, as proposed in the issue:

{
  "work_item": {
    "rules": [
      { "field": "action", "operator": "in", "value": ["status_changed"] },
      { "field": "status.name", "operator": "in", "value": ["<status name>"] }
    ]
  }
}

Matching is on the status display name, for example "In progress".

Behavior change to note

Gitlab::FilterEvaluator#dig_value now returns no match when an intermediate path segment is missing from the event data, instead of raising NoMethodError and failing the whole filter.

	Before	After
Missing intermediate path segment	Raises NoMethodError, failing the whole filter evaluation	Returns no match for that rule; other rules still evaluate

Rules in a scope are AND-ed by default. Without this fix, a status.name rule next to a created action rule made the created trigger never fire.

Under match: any, this is a behavior change for every consumer of the evaluator, including webhook and integration filters: a filter with one unresolvable rule and one matching rule now evaluates to true. A spec covers that case.

Before merging

Once merged, any existing work_item filter with a field other than action or status.name fails validation on its next save. One known shape is the bare status field from the experiment in the issue. Such filters never matched anything, so no trigger loses behavior it had, but their owners would hit a validation error when editing the trigger. Options:

• Check ai_flow_triggers rows for work_item filters with other fields and clean them up or contact the owners.
• Add a compatibility mapping for the legacy status field in a follow-up.

Resolves #607577 (closed)

References

• Issue: #607577 (closed)
• Stacked frontend MR (trigger form status listbox): !254848 (merged)

Screenshots or screen recordings

Not applicable, backend only. The UI is in the stacked frontend MR.

How to set up and validate locally

1. In GDK, use a project that has a flow trigger service account configured.

2. Create a work item trigger through GraphQL with this filter, replacing the status name with one that exists in the project:

   { "work_item": { "rules": [
     { "field": "action", "operator": "in", "value": ["status_changed"] },
     { "field": "status.name", "operator": "in", "value": ["In progress"] }
   ] } }

3. Change a work item's status to "In progress" and confirm a flow session starts.

4. Change the work item to a different status and confirm no flow session starts.

MR acceptance checklist

This MR has been evaluated against the MR acceptance checklist.

🤖 Description is generated with the help of AI