Previously, the API to retrieve discussions from merge requests often
generated hundreds of Gitaly calls to determine whether a system note
should be shown to the user. It did this by:
1. Rendering the Markdown
2. Extracting cross-references from the Markdown
3. For cross-references that were commits, a Gitaly FindCommit RPC
would be issued to validate that the commit exists.
The last step is unnecessary because we don't need to display a commit
if the user doesn't have access to the project in the first place.
`RendersNotes#prepare_notes_for_rendering` is already used in
`MergeRequestsController`, which is why we don't see N+1 Gitaly calls
there. We use it here to optimize the note redaction process.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/65957
Fix missing iid query on NotesFinder
Changed parameters of find_noteable,
so changes across a few files were needed.
MergeRequest also requires iid instead of id query
Make NotesFinder fail with RecordNotFound again
Add specs for target_iid
Using RSpec tablesyntax for target_iid specs
Revert "Using RSpec tablesyntax for target_iid specs"
This reverts commit ba45c7f569a.
Allow find_by! here
Fix variable name
Add readable check
Revert "Add readable check"
This reverts commit 9e3a1a7aa39.
Remove unnecessary assignment
Add required changes for EE
Fix parameter count
Reduce code duplication by extracting a noteable module method
The call to find_noteable was redundant so
multiple files and lines have changed in that
commit to use the newly introduced module
method `noteable`.
Replace casecmp with include check
Add parent_type parameter
Revert "Reduce code duplication by extracting
a noteable module method"
This reverts commit 8c0923babff16.
Method is no longer needed
Check whether noteable can be read by user
If you can do this in the UI, you should be able to do it in the API. If
a discussion is not a single note discussion, or it is replyable, you
can reply to it.
This replaces API::Notes::NOTEABLE_TYPES and
API::Discussions::NOTEABLE_TYPES with class methods defined in a
separate helper modules. This allows EE to extend the list of noteable
types, without having to modify the constant in-place. We can't define
these methods directly in the API classes, as they would be used before
we're able to extend them in EE.
* adds basic discussions API for issues and snippets
* reorganizes notes specs (so same tests can be used for all noteable types - issues, MRs, snippets)
GitLab Bot