Workitem: Calculate the rolledup start/due dates in the whole WorkItem hierarchy
The problem
With Add WorkItem RolledupDates widget and graphql (#434834 - closed) we are now able to create Epic WorkItems with fixed or rolledup dates. However, we are not updating the whole WorkItem hierarchy when rolledup dates are used nested Epic WorkItems. For example, considering the Epic hierarchy, where all the epics are using rolledup dates:
Epic 1
|- Epic 1.1
|- Epic 1.1.1
|- Issue 1
When creating the Issue 1
, we need to update all the parent epics start/due dates to point to the Issue 1
start/due date. So:
- First update
Epic 1.1.1
- Check if
Epic 1.1.1
parent (Epic 1.1
) has rolledup dates, if so update its dates - Check if
Epic 1.1
parent (Epic 1
) has rolledup dates, if so update its dates
Proposed solution
There's some events that will trigger this cascated update, so I propose to use Gitlab Event Store as the event bus mechanism (PubSub). This way, the events wouldn't be attached to a specific behavior, which could make them re-usable for other cases in the future. Some events that required the Epic tree dates to be recalculated(I might be missing somethings here):
-
when a new work_item is created the hierarchy !143956 (merged) (This one was done in isolation as it introduced the event handling strategy, the following one can be done in parallel) -
when a work_item in the hierarchy changes its start/due dates !146208 (merged) -
when a work_item is removed from the hierarchy !146630 (merged) -
when a work_item in the hierarchy changes its Milestone !146988 (merged) -
when adding an existing work_item to the hierarchy (without deleting/creating) !147984 (merged) - related to: #409937 (comment 1826342903) - we probably will have to check if the
hierarchyWidget
changed in the udpate withchildrenIds
- related to: #409937 (comment 1826342903) - we probably will have to check if the
-
when removing an work_item from the hierarchy !148191 (merged) -
when a Milestone changes its start/due dates !146703 (merged) -
when a Milestone is deleted !153183 (merged) (dependent on the MR above)
Feature flag
This is behind the work_items_rolledup_dates
feature flag due to the iterative approach of this implementation.
Further discussion on this proposal in: #425201 (comment 1652166983)