Inherit children epics start and due dates
Parent epics currently do not inherit their children epic's due dates. This is an issue for users of GitLab who are planning and managing projects as parent epic due dates are typically incorrect, unless managed tightly.
- An epic's dates can take on its issue's milestone dates.
- We should expand that existing feature, so it considers its subepics' dates automatically too.
- In particular, we should not introduce any new options in the date fields for epics. It should continue to have only two options: Fixed versus Inherited/Dynamic. Fixed logic doesn't change. (It's just fixed.) Inherited logic does change.
- If you are considering the start date of an epic, and you have chosen Inherited mode, then you look at all your issues and subepics (only at the first level), and look at all those milestone start dates (of those issues), and all those subepic start dates. The earliest of all those dates becomes this inherited start date.
- Same as the inherited due date.
- If you are in manual mode, nothing changes. You just take whatever is the manual date you set.
- So this logic design is consistent with inheriting issue milestone dates. And furthermore, if you change one epic deeply nested inside a tree, that change should bubble up all the way to the top, if it becomes the "extreme" date and is applicable.
Simple label change from
From milestone to
Inherited and updated tooltip text for when
Inherited: None explaining how it works or a more generic text and move the more detailed explanation to docs.