Fix dates inheritance on Epics
What does this MR do and why?
This code change removes filtering restrictions that were limiting which types of work items could be used when calculating rolled-up dates. Previously, the system only allowed specific work item types (issues for milestones, epics for date sources) when determining dates that should be inherited from child items. Now it accepts any work item type, making the date calculation more flexible.
Context
- This MR was started as a fix for the dates inheritance as shown in the attached screenshots in the description
- However we have a bug fix on move work item that was not copying dates that we are asked to backport: !205508 (merged).
- Since this bug is closely related to the inheritance bug(i.e. without fixing the inheritance bug it would appear as dates are not copied correctly) and to avoid creating 6 additional MRs for back-porting, I decided that it would make sense to review the 2 MRs separately but merge only one into master and have less backport MRs
😊
Database
- without filtering types(original): https://console.postgres.ai/gitlab/gitlab-production-main/sessions/43765/commands/133719
- with filtering on types(changed): https://console.postgres.ai/gitlab/gitlab-production-main/sessions/43765/commands/133720
References
Screenshots or screen recordings
| Before | After |
|---|---|
| dates-ineritance-before | dates-inheritance-after |
How to set up and validate locally
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Edited by Alexandru Croitor