[Frontend only] Batch comments on merge requests
What does this MR do?
This MR implements the rest of the frontend work left for #1984 (closed), standing on top of !4213 (merged)
Status of Features
-
Start a review by posting the first draft -
Add drafts to existing review -
Show Review bar at the bottom of the screen -
Make Review Bar display regardless of which tab is selected -
Show Reviews count -
Submit Review -
Dismiss Review
-
-
Show Drafts in the diff line -
Inline view -
Parallel view -
Show the correct content for the Draft -
Show discussion resolution status on draft -
Add actions to draft: -
edit -
delete (still might need refactoring)
-
-
Publish draft individually
-
-
Send resolve/unresolve status -
Check that quick actions work at least in Discussion tab -
They don't. Need to add support to Draft Note vue component to list actions to be taken when published (per mockup)
-
Status of low-level tasks
-
Render drafts using same mechanism as discussions (incremental rendering, after diffs) -
Use old icons for actions (edit / delete) to sync-up visually with the Notes' ones -
create follow-up issue
-
-
Rewrite mixin (experiment) inwe kept the mixin. ...app/assets/javascripts/diffs/components/diff_line_note_form.vue
to an action in the batchComments store module
Bugs to fix
-
Don't fetch/render drafts when signed out -
Clear form properly after draft submission -
Prevent Batch Comments logic in Issues (start a discussion in an issue is broken) -
Don't display batch comments buttons while editing a current existing note/draft. -
Drafts are shown on same line of all files changed (need to add an extra check)
Nice-to-haves for first release
-
Improve "pending" area of Draft (see discussion). -
Improve badge style when “Submit review” button is disabled/loading (screenshot) -
Set drafts on lines upon fetching, as we do with discussions (follow up)
Tests tasks
-
Add a complete feature test to ensure with breaks if a conflict is badly resolved between CE-EE
What are the relevant issue numbers?
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
Tests added for this feature/bug -
Conforms to the code review guidelines -
Conforms to the merge request performance guidelines -
Conforms to the style guides -
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?
Edited by 🤖 GitLab Bot 🤖