Set a `sha` parameter on the MR form. If this doesn't match the HEAD of
the source branch when the form is submitted, show a warning (like with
a merge conflict) and don't merge the branch.
The `sha` parameter is optional, and when present, must match the
current HEAD SHA of the source branch. Otherwise, the API call fails
with a 409 Conflict and a message containing the current HEAD for the
source branch.
Also tidy up some doc wording.
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
There are several changes to this module:
1. The use of an explicit stack in Participable#participants
2. Proc behaviour has been changed
3. Batch permissions checking
== Explicit Stack
Participable#participants no longer uses recursion to process "self" and
all child objects, instead it uses an Array and processes objects in
breadth-first order. This allows us to for example create a single
Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
a ReferenceExtractor removes the need for running potentially many SQL
queries every time a Proc is called on a new object.
== Proc Behaviour Changed
Previously a Proc in Participable was expected to return an Array of
User instances. This has been changed and instead it's now expected that
a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
value of the Proc is ignored.
== Permissions Checking
The method Participable#participants uses
Ability.users_that_can_read_project to check if the returned users have
access to the project of "self" _without_ running multiple SQL queries
for every user.
Fix cancelability and retriablity of pipeline with generic statuses
Currently it's not possible to cancel or retry generic status since this is external thing to GitLab.
This fixes shown actions of pipelines containing only these actions.
See merge request !4380
Use project that belongs to pipeline in view
## What does this MR do?
This MR makes project in pipelines view match the one that pipeline has been created for.
Closes#17943
See merge request !4376
Pass the "Remember me" value to the 2FA token form
Prior, if a user had 2FA enabled and checked the "Remember me" field,
the setting was ignored because the OTP input was on a new form and the
value was never passed.
Closes#18000
See merge request !4369
Fix 404 page when viewing TODOs that contain milestones or labels in different projects
A user viewing the TODOs page will see a 404 if there are mentioned milestones or 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 expands the `project_ref` to the right value as soon as we have it to avoid this caching bug.
Closes#17898
See merge request !4312
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
Include Wiki attributes in Wiki page events webhook
The hook data we are sending is not 100% correct (we send details of the project, but should also send details of the "ProjectWiki" attributes like URLs and repositories relative to the wiki itself).
This is a follow up to #17506Fixes#17507
See merge request !4138
Make authentication service for Container Registry to be compatible with < Docker 1.11
This removes the usage of `offline_token` which is only present when using `Docker 1.11.x` instead we relay on `scope`. This should make it compatible with any client starting from 1.6 (I did test only 1.8 and up).
Right now we return 403 if unauthorized user doesn't have access to anything. In all other cases we return token, but with empty `access`, which simply disallow requested action.
See merge request !4363
Prior, if a user had 2FA enabled and checked the "Remember me" field,
the setting was ignored because the OTP input was on a new form and the
value was never passed.
Closes#18000
Sean McGivern
Stan Hu
Douwe Maan
Yorick Peterse
Rémy Coutable
Douwe Maan
Kamil Trzcinski
Grzegorz Bizon
Dmitriy Zaporozhets
Felipe Artur
Robert Speicher
Valery Sizov
Gabriel Mazetto
Robert Speicher
Long Nguyen
Zeger-Jan van de WegandStan Hu
DJ Mountney
Jacob Schatz
Alfredo Sumaran