Add upvote/downvote fields to merge request and note API to preserve compatibility
As discussed in !1825 we should not break the API compatibility.
* This MR adds the fields `upvotes`/`downvotes` to the merge request API again, which always return `0`.
* Add the fields `upvote`/`downvote` to the notes API, which always return `false`
This behavior is documented in the API docs.
See merge request !1867
Award Emoji
This it first iteration of award emoji feature.
We have plan to extend emoji picker by the next release.
For now, you can add award by clicking to the emoji picker or posting a regular comment with emoji like "👍" and any other. You can post not only emoji that listed in the emoji picker.
See merge request !1825
This ensures that when viewing an issue each note already has the
associated project, project members, group and group members available.
Since this information is requres for every note this results in quite
the reduction of SQL queries being executed.
**What does this do?**
It makes sure that whenever a new note is added to an noteable item, the
updated_at of that item is also updated.
**Why is this needed?**
At this moment when you post a comment on an issue or add a label to an issue,
the updated_at is not changed. Because of this the filtering for least recently
updated is not really useful (since it only takes in account the original text
from the noteable).
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
Update mentionable shared examples to be (a bit) more understandable
These shared examples were super confusing, and honestly still kind of are, but they should be a bit better now.
I encountered a bunch of headaches in these examples while refactoring ReferenceExtractor, so that's how I ended up changing it.
See merge request !1780
Having a merge request with a comments on a line which is then changed
in a later commit prevented new comments from properly showing up in the
merge request show page.
* `Note#set_diff` do not use stored the diff when creating a new note
in merge requests (we can not be sure the diff did not changed since
the last comment on that line)
* Do not rely just on `outdated?` of the first note when displaying
comments of a MR in the discussion tab, but partition the
active/outdated notes and display them all
* In the inline changes tab just select the active notes, so an
outdated note does not prevent an active one from being rendered
* Just show active comments in the side-by-side changes tab
Supports four different event types all bundled under the "note" event type:
- comments on a commit
- comments on an issue
- comments on a merge request
- comments on a code snippet