Add support for cross project references for labels
## Summary
Support for cross project references for labels.
## Rationale
1. Cross project label references are currently not supported in GitLab
1. `to_reference` method signature in `Label` model breaks the abstraction introduced in `Referable`.
`concerns/referable.rb: def to_reference(_from_project = nil)`
Signatures:
```
label.rb: def to_reference(format = :id)
commit_range.rb: def to_reference(from_project = nil)
commit.rb: def to_reference(from_project = nil)
external_issue.rb: def to_reference(_from_project = nil)
group.rb: def to_reference(_from_project = nil)
issue.rb: def to_reference(from_project = nil)
merge_request.rb: def to_reference(from_project = nil)
milestone.rb: def to_reference(from_project = nil)
project.rb: def to_reference(_from_project = nil)
snippet.rb: def to_reference(from_project = nil)
user.rb: def to_reference(_from_project = nil)
```
This MR suggests using `def to_reference(from_project = nil, format: :id)` which makes use of keyword arguments and preserves abstract interface.
1. We need support for cross project label references when we want to move issue to another project
It may happen that issue description, system notes or comments contain reference to label and this reference will be invalid after moving issue to another project and will not be displayed correctly unless we have support for cross project references.
Merge request that needs this feature: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2831
I think that cross project label references may be useful, (example: `Hey, see our issues for CI in GitLab CE! - gitab-org/gitlab-ce~"CI"`).
cc @JobV @DouweM @rspeicher
See merge request !2966
Indicate when an MR diverged from the target branch
This adds an indicator to the "Merge MR" box, to tell if and how much an MR diverged from its target branch.
For instance, consider an MR to merge the branch `feature` into `master`. Some other commits were added to `master` since `feature` was created, and the two branches diverged.
```text
o master
|
o o feature
| |
o o
| /
o
```
In this case, there will be a label in the MR Merge box stating:
> This MR is by 3 commits behind the target branch `master`.
## Screenshots
### The branch diverged from the target (UI Proposal)
### The branch diverged from the target (alternative UI Proposal)
## How is this useful?
- In a _rebase-workflow_ (MR are preferably rebased before being merged), the reviewer wants to know if an MR is rebased on the target branch before merging it.
_With this indicator, the reviewer knows immediately if the branch is rebased, or if she needs to ask the committer to rebase its branch._
<br>
- To keep the git history readable, a team prefers to avoid merging branches that really lag a lot behind the target branch. Merging an MR that is 10 commits behind is fine, but 200 is too much.
_With this indicator, the reviewer can see on the MR page if the branch is really far behind the target – or only a few commits behind._
## Open questions
We've been using this at @captaintrain for a few months now, and found it quite useful.
I guess the open-questions are mostly: what UI would be the more adequate? Any thoughts on this, on the general usefulness and/or on the code?
See merge request !2217
Make better use of the `Note#for_*?` methods
We've got all these polymorphic type-checking methods, might as well use
'em everywhere it makes sense.
See merge request !3106
Flush repository caches before renaming projects
This should hopefully solve gitlab-org/gitlab-ce#13790. Once I know the exact steps to reproduce the problem I should be able to confirm this.
cc @dblessing @inem
See merge request !2974
Properly check for a pre-existing error in `User#namespace_uniq`
Rails adds an empty error to the Errors object even if you just call
`#[]` on it:
```
[1] pry(main)> u = User.last
[2] pry(main)> u.errors.keys
=> []
[3] pry(main)> u.errors[:username].present?
=> false
[4] pry(main)> u.errors.keys
=> [:username]
```
See merge request !3017
Rails adds an empty error to the Errors object even if you just call
`#[]` on it:
```
[1] pry(main)> u = User.last
[2] pry(main)> u.errors.keys
=> []
[3] pry(main)> u.errors[:username].present?
=> false
[4] pry(main)> u.errors.keys
=> [:username]
```
Prior, if the user enabled 2FA, then disabled it and came back some time
after the grace period expired, they would be forced to enable 2FA
immediately.
Branded appearance to CE
Closes#11489
The difference with the EE version is only that there is no distinction between light and dark logos, though this wasn't used anyway. If this is fine, I'll create a MR on EE too.
TODO:
- [x] Copy docs
- [x] Make new screenshots
- [ ] Remove Custom Welcome message feature?
@rymai: I was unsure what labels to add to ping you, so I just ping you like this 😉
/cc @DouweM
See merge request !2927
The only major difference with the EE version is the change from a light and dark logo to only a header logo
The dark logo wasn't used anyway, so it seemed to make sense to me to rename the field to the actual function of it
This ensures that if a project is later re-created using the old path it
doesn't end up re-using the old cache. This also ensures we don't keep
the cache around until its expired by Redis itself.
Fixesgitlab-org/gitlab-ce#13790
Douwe Maan
Douwe Maan
Robert Speicher
Dmitriy Zaporozhets
Jacob Schatz
Jacob Vosmaer
Rémy Coutable
Rubén Dávila
Pierre de La Morinerie
Grzegorz Bizon
Robert Speicher
Alfredo Sumaran
Zeger-Jan van de Weg
Yorick Peterse