GitLab Next

The CE port is at https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20687

What does this MR do?

Allow obtaining an epic's start/due dates based on its issues' milestones.

Are there points in the code the reviewer needs to double check?

Why was this MR needed?

Allow setting/updating dates automatically so users don't have to. Backend part of #6470 (closed)

Screenshots (if relevant)

https://www.youtube.com/watch?v=uoyygR0_33w&feature=youtu.be

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• API support added
• Tests added for this feature/bug
• Conform by the code review guidelines
  • Has been reviewed by a UX Designer
  • Has been reviewed by a Frontend maintainer
  • Has been reviewed by a Backend maintainer
  • Has been reviewed by a Database specialist
• EE specific content should be in the top level /ee folder
• Conform by the merge request performance guides
• Conform by the style guides
• Conform by the database guides
• If you have multiple commits, please combine them into a few logically organized commits by squashing them
• Internationalization required/considered
• If paid feature, have we considered GitLab.com plan and how it works for groups and is there a design for promoting it to users who aren't on the correct plan
• End-to-end tests pass (package-and-qa manual pipeline job)

What are the relevant issue numbers?

Closes #6470 (closed)

Design decisions

Since epic sorting is needed on the database level, the overall composite start/due date values need to be stored in the database. The existing start_date and end_date will act as this composite date.

Scenarios when this composite column needs to be updates

• When epic _fixed and is_fixed are changed (Epics::UpdateService)
• When issue is assigned/unassigned to epic (EpicIssues::CreateService, EpicIssues::DestroyService)
• When issue milestone is changed (Issues::UpdateService)
• When milestone dates are changed (Milestones::UpdateService)