| Age | Commit message (Collapse) | Author |
|---|
|
Since !18150 abstract reference filter supports also `group`
as a resource parent (not only `project`). Some reference filters,
which inherit from abstract filter, depend on parent being `project`
when checking a reference.
This patch adds explicit check of parent class to the given filters.
|
|
Add support for patch link extension for commit links on GFM
Closes #17939
See merge request gitlab-org/gitlab-ce!18229
|
|
|
|
Updates notes-related services and rendering so this code can be
easily used for group-scoped resources (specifically Epics).
Related to gitlab-ee!5205
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We had a lot of copied and pasted code, when the different elements were very
small and easy to get wrong.
|
|
Group milestones can only be referred to by name, not IID. They also do not
support cross-project references.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
|
|
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/18096
|
|
|
|
Before we weren’t caching current_project_ref because normally the reference to
the current project doesn’t include the path with namespace. But now we store
the current project in the projects reference cache to be used for the same
filter when accessing using path with namespace of for subsequent filters executed on the cache.
|
|
|
|
IssueReferenceFilter will end up processing internal issue references
when a project uses an external issues tracker while still using
internal issue references (in the form of `#\d+`). This commit ensures
that these links are rendered as external issue links, regardless of
whether the project one currently views uses an internal or external
issues tracker.
Fixes gitlab-org/gitlab-ce#19036, gitlab-com/performance#16
|
|
of max database values
When using #XYZ in Markdown text, if XYZ exceeds the maximum value of a signed 32-bit integer, we
get an exception when the Markdown render attempts to run `where(iids: XYZ)`. Introduce a method
that will throw out out-of-bounds values.
Closes #18777
|
|
This reduces the number of queries executed in IssueReferenceFilter by
retrieving the various projects/issues that may be referenced in batches
_before_ iterating over all the HTML nodes.
A chunk of the logic resides in AbstractReferenceFilter so it can be
re-used by other filters in the future.
|
|
Separate reference gathering from rendering
This is a required step to allow batch processing when gathering references. This in turn would allow grabbing (for example) all mentioned users of an issue/merge request using a single query.
cc @rspeicher @DouweM
See merge request !3969
|
|
different projects
A user viewing the TODOs page will see a 404 if there are mentioned labels
in multiple different projects. This is likely a caching bug and only occurs
when Markdown rendering occurs across multiple projects, which is why it's so
tricky to reproduce. This is what I think is happening:
1. LabelReferenceFilter#references_in encounters label ~X for ProjectA and finds the label in the DB as id = 1.
2. LabelReferenceFilter.references_in yields [1, 'X', nil, ...]
3. Since project_ref is nil, AbstractReferenceFilter#project_from_ref_cache caches nil => ProjectA.
4. LabelReferenceFilter#references_in encounters label ~Y for ProjectB and finds the label in the DB as id = 2.
5. LabelReferenceFilter.references_in yields [2, 'Y', nil, ...]
6. AbstractReferenceFilter#project_from_ref_cache lookups nil and returns ProjectA. It was supposed to be ProjectB.
7. A is the wrong project, so the label lookup fails.
This MR caches Markdown references if the key is present.
Closes #17898
|
|
This splits the Markdown rendering and reference extraction phases into
two distinct code bases. The reference extraction phase no longer relies
on the html-pipeline Gem (and any related code) and allows for
extracting of references from multiple HTML nodes in a single pass. This
means that if you want to extract user references from 200 comments you
no longer need to run 200 times N number of queries, instead only a
handful of queries may be needed.
|
|
This fixes the problem where Markdown such as:
### 31st
Would get rendered as a link tag pointing to issue number 31 inside a
header tag.
See gitlab-org/gitlab-ce#14936 for more information.
|
|
Cleaning this up any further is a bit tricky as the caches in question
should only be evaluated if RequestStore is actually enabled.
|
|
For an issue with around 200 notes this cuts down timings by around 150
milliseconds.
|
|
These methods always return the same data for every class so there's no
point in computing their values on every call.
|
|
These filters now use a single iteration over all the document nodes
instead of multiple ones. This in turn allows variables to be re-used
(e.g. links only have to be unescaped once). Combined with some other
refactoring this can drastically reduce render timings.
|
|
This was originally suggested by @ayufan and modified to be a bit
cleaner and use RequestStore instead of a regular Hash.
By caching the output of the two methods involved the number of queries
is reduced significantly. For example, for an issue with 200 notes (of
which 100 reference a number of merge requests) this cuts down the
amount of queries from around 6300 to around 3300.
|
|
When `object_class.link_reference_pattern` was `nil` because object
being processed do not implemement link references `call` method
returned `nil` instead of returning document, even if document has been
processed in for basic reference pattern.
|
|
|
|
|
|
Around 300 ms (in total) would be spent in these delegated methods due
to the extra stuff ActiveSupport adds to the compiled methods. Because
these delegations are so simple we can just manually define the methods,
saving around 275 milliseconds.
|
|
|
|
|
|
|
|
|
|
|
