Add API for reordering child epics

What does this MR do?

Add API for reordering child epics

Also makes the listing API return an ordered list of child epics

What are the relevant issue numbers?

Closes #7328 (closed)

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated via this MR
• Documentation reviewed by technical writer or follow-up review issue created
• Tests added for this feature/bug
• Tested in all supported browsers
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides
• Conforms to the database guides
• Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process.
• EE specific content should be in the top level /ee folder
• For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan?
• Security reports checked/validated by reviewer

changed milestone to %11.9

added Deliverable GitLab Ultimate Plan [DEPRECATED] backend customer direction epics frontend missed:11.8 workflowin review + 1 deleted label

added 1 commit

• c6d7d3c8 - Add API for reordering child epics

Compare with previous version

marked the checklist item Changelog entry added, if necessary as completed

marked the checklist item Documentation created/updated via this MR as completed

marked the checklist item Tests added for this feature/bug as completed

removed frontend workflowin review labels

@mikelewis Can you review the docs changes here? Thanks

@jarka Can you take a look? This is a follow-up MR to add an API for reordering. Thanks

assigned to @jarka

	1 Warning
	This merge request is missing the ~Documentation label.

	1 Message
	This merge request adds or changes files that require a review from the Technical Writing team whether before or after merging.

Documentation review

The following files will require a review from the Technical Writing team:

• doc/api/epic_links.md

Per the documentation workflows, the review may occur prior to merging this MR or after a maintainer has agreed to review and merge this MR without a tech writer review. (Meanwhile, you are welcome to involve a technical writer at any time if you have questions about writing or updating the documentation. GitLabbers are also welcome to use the #docs channel on Slack.)

The technical writer who, by default, will review this content or collaborate as needed is dependent on the DevOps stage to which the content applies:

Tech writer	Stage(s)
@marcia	~Create ~Release + development guidelines
@axil	~Distribution ~Gitaly ~Gitter ~Monitor ~Package ~Secure
@eread	~Manage ~Configure ~Geo ~Verify
@mikelewis	~Plan

To request a review prior to merging

• Assign the MR to the applicable technical writer, above. If you are not sure which category the change falls within, or the change is not part of one of these categories, mention one of the usernames above.

To request a review to commence after merging

• Create an issue for a doc review using the Doc Review template and assign it to the applicable technicial writer from the table.

Reviewer roulette

Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.

To spread load more evenly across eligible reviewers, Danger has randomly picked a candidate for each review slot. Feel free to override this selection if you think someone else would be better-suited, or the chosen person is unavailable.

Once you've decided who will review this merge request, mention them as you normally would! Danger does not (yet?) automatically notify them for you.

Category	Reviewer	Maintainer
~Documentation		Mike Lewis (@mikelewis)
backend	Bob Van Landuyt (@reprazent)	Rémy Coutable (@rymai)

Generated by Danger

added 8 commits

• c6d7d3c8...fc367078 - 7 commits from branch master
• 96b681bd - Add API for reordering child epics

Compare with previous version

Thanks @engwan , looks good

assigned to @engwan

@dbalexandre can you review / merge? Thanks

assigned to @dbalexandre

@engwan Please note Douglas is OOO.

Yeah, I just noticed too when I checked his Slack profile. GitLab status wasn't updated.

Thanks @mkozono.

@godfat Can you review / merge this? Thanks

assigned to @godfat

@engwan Thanks! Just one typo. The way move_before_id and move_after_id work surprised me a lot. I thought it's moving the child before that, not put that before the child. But surely what's done is done, not relevant here.

assigned to @engwan

I'll apply and squash merge later if you're ok with that. I am moving out, will get back later.

added 1 commit

• 0bc9af09 - Apply suggestion to doc/api/epic_links.md

Compare with previous version

Thanks @godfat. Applied the code suggestion.

The way move_before_id and move_after_id work surprised me a lot. I thought it's moving the child before that, not put that before the child. But surely what's done is done, not relevant here.

That confused me at first too. It's hard to change the param names now because we also want it to be consistent with the API for ordering of Issues within Epics.

I thought of improving the description of the params in the docs to make this clearer. But I'm not sure how.

move_before_id: The global ID of a sibling epic that should be placed before the child epic. makes it seem like we're moving the move_before_id epic but in reality we're moving the child epic to be after that epic.

I didn't want to use something like: The child epic will be moved after this child epic, because we'd have before and after on the same line and I thought that would confuse users more.

added 423 commits

• 0bc9af09...50029c15 - 422 commits from branch master
• e8548886 - Add API for reordering child epics

Compare with previous version

approved this merge request

@engwan Yeah, I think the current description is actually pretty clear. The problem is that the name move_before_id and move_after_id. I think it's probably more clear if they're just before_id and after_id. That "move" is pretty confusing. Anyway, we should certainly be consistent and the decision was already made.

The errors were coming from master: https://gitlab.com/gitlab-org/gitlab-ee/issues/10211 so I am approving. We might want to wait for master to become green before merging this though.

added 130 commits

• e8548886...69676ec1 - 129 commits from branch master
• c81c9025 - Add API for reordering child epics

Compare with previous version

@godfat Pipeline is now

assigned to @godfat

@engwan Awesome, thanks!

resolved all discussions

merged

mentioned in commit 43bcc1bf

mentioned in issue gitlab-org/release/tasks#700 (closed)

added devopsplan label

added Enterprise Edition label

added Category:Portfolio Management label

removed Plan [DEPRECATED] label