Inherit issue milestone dates as epic dates
Problem
- Currently, epics have a planned start date and a planned end date, which are manually entered.
- This is useful in the general case. But for GitLab usage, it is not, because we use milestones and their dates to do planning and scheduling.
- We should integrate milestones with epics directly.
Design
-
https://gitlab.com/gitlab-org/gitlab-ee/issues/6470 — Inherit milestone dates or fixed dates:
- Remove the date picker validations (disabled dates based on the current start or finish date)
- For the planned start and finish dates of an epic, you can choose whether to inherit the most appropriate milestone start and end dates of the epic's issues. Or you can choose to enter the start and end dates with manual values.
- By default, the epic dates are inherited from the milestones.
- When the user saves a fixed date, that date’s mode should change to fixed automatically (if it isn’t already). But if they cancel out of the calendar UI, the selection of mode shouldn’t change.
- So for each date, the DB needs to at least store: The fixed value, which can be none; A flag indicating whether the user wants to use the fixed value or the inherit value. Since the fixed value is saved, when the user toggles between modes, the fixed value is still there, it was just hidden from the user.
- You can manually set inherit mode vs fixed mode per date. I.e. both dates are independent on which mode you set.
- The UI of the epic page should clearly indicate when the dates are inheriting or have a fixed value.
- There's a DB record that stores the manual start date and a DB record that stores the manual end date.
- Inherit date logic:
- For the planned start date: If that date is in auto mode, look at all all linked milestones of all issues that are linked to the epic. The earliest (closest to negativity infinity time) milestone start date automatically becomes the epic's planned start date. If there is no non-null value found, then the result of the algorithm is simply None.
- For the planned end date is exactly analogous, but for closest to positive infinity time milestone end date.
- Be careful: The epic planned start date algorithm looks at milestone start dates only, and the epic planned end date algorithm looks at milestone end dates only.
- If milestone's start date is after another milestone's end date, the epic should not inherit those dates and inform the user that there is a conflict.
- The inherit start date and the inherit end dates are dynamic, and depend on the state of the milestones of the issues in the epic at the current moment. There are many ways that the epic dates can change while in auto mode:
- Milestone start/end dates can change.
- Milestones can be added/removed to/from issues.
- Issues can be added/removed to/from the epic.
- Also be careful, we don’t care whether a milestone is open or closed in this algorithm.
-
https://gitlab.com/gitlab-org/gitlab-ee/issues/6802 — Epic roadmap changes:
- This view is unchanged in terms of the bars and the logic of how they are drawn in the timeline. But now the left edge and the right edge of a bar reflect whatever value is selected in the epic (manual or auto).
- We show project or group milestones in this view — but only milestones of issues contained in the epics being shown. This gives an indication of how epics are being shaped around milestones.
- When the roadmap page loads, if there is a conflict, the epic bar is not shown.
Edited by Pedro Moreira da Silva