## Background - A flow trigger with the `work_item` event type can filter on `action` and `status.name`. It cannot filter on the work item type. - One status name can belong to the lifecycles of more than one type. In `gitlab-org`, each status of the Task lifecycle is also a status of the Issue lifecycle. - So a trigger with `status.name in [In dev]` starts a flow for a Task and also for an Issue. A flow that must run on each child Task also starts when a human moves the parent Issue. - https://gitlab.com/gitlab-org/gitlab/-/work_items/604491 asks for a work item type control on both work item actions. This task delivers that control. The "From status" control of that issue is out of scope. ## Proposal Filter on the ID of the work item type, not on its base type. ```json { "work_item": { "rules": [ { "field": "action", "operator": "in", "value": ["status_changed"] }, { "field": "status.name", "operator": "in", "value": ["In dev"] }, { "field": "work_item_type_id", "operator": "in", "value": [5] } ] } } ``` Backend: 1. Add `work_item_type_id` to the event data of `WorkItems::BaseEvent` in `app/events/work_items/base_event.rb`. Do not make it a required field, so that the events in the queue during a deploy stay valid. 1. Add `'work_item_type_id' => cloud_event.event_data[:work_item_type_id]` to `filter_data_extras` in the two work item workers: - `Ai::Catalog::Flows::ExecuteWorkItemCreatedWorkflowTriggersWorker` - `Ai::Catalog::Flows::ExecuteWorkItemStatusChangedWorkflowTriggersWorker` 1. Allow `work_item_type_id` in `Ai::FlowTrigger::ALLOWED_FILTER_FIELDS['work_item']`. Refuse a value that is not the ID of a work item type of the trigger namespace. 1. Add `work_item_type_id` to the filter data of `Ai::FlowTriggers::ApplyOnFinishSettingsWorker#still_matches_filter?`. Without it, a trigger with a type rule never applies its on-finish settings. Frontend: 1. Add a type listbox to `work_item_events_configuration.vue` for both work item actions. - The options come from the `namespaceWorkItemTypes` query that the form already runs. The value is the numeric part of `id`, and the text is `name`. - The form owns the `work_item_type_id` rule, as it owns the `status.name` rule. It keeps the rules of other fields. - Every work item event has a type, so the type rule does not block the "Created" action. 1. When types are selected, the status list shows only the statuses of those types. The form does not keep a selected status that the selected types do not have. The on-finish status list of https://gitlab.com/gitlab-org/gitlab/-/merge_requests/261553 uses the same rule. Docs: 1. Document the filter in `doc/user/duo_agent_platform/triggers/_index.md`, with the API field and the IDs of the system-defined types. Delivery: The backend MR is part of one stack: 1. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/261137, the on-finish settings backend. 1. The backend MR of this task. After this MR, the filter is available through the GraphQL API. 1. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/261553, the on-finish settings form. The frontend and docs of this task come after the backend MR, because they change the same form as https://gitlab.com/gitlab-org/gitlab/-/merge_requests/261553. <details> <summary>Why the type ID, and the differences from the parent issue</summary> Why the ID: - The base type is not exact for custom work item types. A custom type that GitLab did not convert from a system-defined type reports `issue`. - So a rule on `issue` also matches each of these custom types. - No base type rule can select one custom type. - A converted type keeps the ID of its system-defined type after a rename. A rule on a type name stops matching after a rename. - GitLab defines the IDs of the system-defined types in code, so they are the same on every instance: - Issue `1`, Incident `2`, Test case `3`, Requirement `4`, Task `5` - Objective `6`, Key result `7`, Epic `8`, Ticket `9` - Custom types get IDs from `1001`. - The `WorkItemType` GraphQL type has no base type field. The form gets `id` and `name`, so it can use the ID with no mapping. - Work item lists, boards, and saved views already filter by type ID with `workItemTypeIds`. - https://gitlab.com/gitlab-org/gitlab/-/work_items/606193 plans to change the `work_item_type` event field from the base type to the type name. - A rule on that field would stop matching after that change, with no error. - A separate `work_item_type_id` field does not depend on that change. - The review discussion that started that issue asks if an ID is possible: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/239419#note_3551320568. Differences from https://gitlab.com/gitlab-org/gitlab/-/work_items/604491: - The field is `work_item_type_id`, not `object_attributes.work_item_type`. The filter data of work item triggers has no `object_attributes` key, and the status rule uses `status.name`. - The values are type IDs, not base types from the `WorkItems::Type` enum, for the reasons above. Checks on `master` at `0b3bd6ab4784` and on a GDK: - `WorkItems::TypesFramework::Custom::Type` delegates `base_type` to its system-defined type, or to Issue when it has none. - A custom type that is not converted has the GID `gid://gitlab/WorkItems::Type/<custom ID>`. A custom type converted from Task has the GID `gid://gitlab/WorkItems::Type/5`. - The `work_item_type_id` column of a work item holds the same ID as its type GID. </details> ## Acceptance - [x] The event data of `WorkItems::CreatedEvent` and `WorkItems::StatusChangedEvent` contains `work_item_type_id`. - [x] A trigger with `work_item_type_id in [5]` starts a flow for a Task, and not for an Issue, for the "Created" and "Status changed" actions. The specs of both workers cover each case. - [x] `Ai::FlowTrigger` refuses a `work_item_type_id` value that is not the ID of a work item type of the trigger namespace. - [x] The trigger form saves and reads one `work_item_type_id` rule for both work item actions, and keeps the rules of other fields. - [x] The trigger form does not keep a selected status that the selected types do not have. - [x] The triggers documentation describes the filter and lists the IDs of the system-defined types. - [x] On a GDK, a trigger with `status.name in [In dev]` and `work_item_type_id in [5]` starts a session for a Task that moves to `In dev`. It does not start a session for an Issue that moves to `In dev`. ## Out of scope - The "From status" control of https://gitlab.com/gitlab-org/gitlab/-/work_items/604491. - A status event when a work item gets its first status at creation. `WorkItems::Callbacks::Status` publishes `WorkItems::StatusChangedEvent` only in `after_update_commit`. ## Source An assessment of a hand-off from the Software Factory work in https://gitlab.com/gitlab-org/dev-bureau/-/work_items/156, checked against the code and on a GDK.