If the UI sends a string value for lock_version (e.g. "0"), then the
previous monkey patch did not properly handle that properly. This
commit casts the value to an integer to determine whether to look for
NULL lock_versions.
For merge requests, GitLab sends a POST request to
`namespace/project/merge_requests/:iid` with the
`merge_request[lock_version]` parameter with a string `0`. The string
value comes from the form field, which explains why
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28145 wasn't
sufficient.
Spam checks are meant for content that could be indexed by search
engines. Confidential issues aren't indexed by search engines, so we
don't need to do spam checks for them.
We do need to check for spam when an issue changes from confidential to
public, even if nothing else changed.
These methods don't really need to be on the Issue model. Issue#related_branches
can also be moved to a service, but we can do that in a separate commit.
This commit does not change any behaviour; it just moves code around, renames
the service, and refactors the specs.
This removes all usage of soft removals except for the "pending delete"
system implemented for projects. This in turn simplifies all the query
plans of the models that used soft removals. Since we don't really use
soft removals for anything useful there's no point in keeping it around.
This _does_ mean that hard removals of issues (which only admins can do
if I'm not mistaken) can influence the "iid" values, but that code is
broken to begin with. More on this (and how to fix it) can be found in
https://gitlab.com/gitlab-org/gitlab-ce/issues/31114.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37447
This throttles the number of UPDATE queries that can be triggered by
calling "touch" on a Note, Issue, or MergeRequest. For Note objects we
also take care of updating the associated "noteable" relation in a
smarter way than Rails does by default.
This ensures the issues/MR cache of the sidebar is only updated when the
state or confidential flags changes, instead of changing this for every
update.
Every project page displays a navigation menu that in turn displays the
number of open issues and merge requests. This means that for every
project page we run two COUNT(*) queries, each taking up roughly 30
milliseconds on GitLab.com. By caching these numbers and refreshing them
whenever necessary we can reduce loading times of all these pages by up
to roughly 60 milliseconds.
The number of open issues does not include confidential issues. This is
a trade-off to keep the code simple and to ensure refreshing the data
only needs 2 COUNT(*) queries instead of 3. A downside is that if a
project only has 5 confidential issues the counter will be set to 0.
Because we now have 3 similar counting service classes the code
previously used in Projects::ForksCountService has mostly been moved to
Projects::CountService, which in turn is reused by the various service
classes.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36622
Jan Provaznik
Brett Walker
Stan Hu
Sean McGivern
Imre Farkas
Andreas Brandl
Thong Kuah
Kamil Trzciński
Michael Kozono
Robert Schilling
Felipe Artur
Jarka Košanová
Mark Chao
Shinya Maeda
Jacopo
Bob Van Landuyt
Yorick Peterse
Oswaldo Ferreira
blackst0ne
George Andrinopoulos
Rémy Coutable
Sean McGivern
Robert Speicher
Grzegorz Bizon
Valery Sizov
Alfredo Sumaran
Douwe Maan
Ruben Davila