Record work item linking events
Background
Work Item is an alias for Issue although we are working on fully transitioning to using work items
You can relate a work item to another work item. For example, you can add or link a work item task to a work item issue.
When a link is made, the link is modeled as WorkItems::ParentLink
and a system note is generated e.g., something like "A task was added to issue".
We want to generate an additional type of record that captures the link as an event using ResourceLinkEvent
.
What does this MR do and why?
-
When
WorkItems::ParentLink
is created or destroyed, respectively via itsCreateService
andDestroyService
, create and store a newResourceLinkEvent
. -
Add a new column to
resource_link_events
table. The column will have a foreign key constraint toSystemNoteMetadata
.-
Why? We want to backfill
resource_link_events
based onsystem_note_metadata
table later. -
resource_link_events
table is currently empty. The table will start being used after the code change in this MR is merged.
-
How to set up and validate locally
- Create an issue (which is a work item) and add a new task.
Near the end of the demo, you can see a system note that reads "Administrator added #11 (closed) as a child task just now."
The information in the note is stored in system_note_metadata
table and that's what I am going to use to backfill resource_link_events
later.
- Check
resource_link_events
table.
WorkItems::ResourceLinkEvent.last
=> #<WorkItems::ResourceLinkEvent:0x00000001522973b0
id: 2,
action: "add",
user_id: 1,
issue_id: 723,
child_work_item_id: 724,
created_at: Thu, 06 Apr 2023 12:29:24.384887000 UTC +00:00,
system_note_metadata_id: 375>
You may also try removing the link (remove the added task via the dot menu.)
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #395491 (closed)