1. Make the "subscribed" text in Issuable sidebar reflect the labels
subscription status
2. Current user mut be logged-in to toggle issue/MR/label subscription
1. Allow subscribing (the current user) to a label
- Refactor the `Subscription` coffeescript class
- The main change is that it accepts a container, and conducts all
DOM queries within its scope. We need this because the labels
page has multiple instances of `Subscription` on the same page.
2. Creating an issue or MR with labels notifies users subscribed to those labels
- Label `has_many` subscribers through subscriptions.
3. Adding a label to an issue or MR notifies users subscribed to those labels
- This only applies to subscribers of the label that has just been
added, not all labels for the issue.
Ignore eager loading in Project.search UNION
This fixes issues such as filtering groups by names on pages such as
https://gitlab.com/dashboard/groups.
See merge request !3229
The queries that are UNION'd together don't need any eager loading
(since we really only use the resulting SQL instead of having
ActiveRecord actually run the queries). By dropping any eager loaded
associations queries such as the following work instead of producing a
SQL error:
Project.all.includes(:namespace).search('foo')
Cleanup Ci::Commit, Ci::Build and CommitStatus views
This MR tries to do first sweep of cleanups to Ci::Commit and
Ci::Build objects removing all view-related functions and fixing the
API from other side.
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/6046
See merge request !2760
Bring from EE: Share Project with Group
- [x] Models and migrations
- [x] Logic, UI
- [x] Tests
- [x] Documentation
- [x] Share with group lock
- [x] Api feature
- [x] Api docs
- [x] Api tests
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
For #12831
cc @DouweM @rspeicher @vsizov
See merge request !3186
- Remove unused Gitlab::Application.routes.url_helpers from Ci::Build
- Remove too much logic from a view, use Ci::Commit.matrix_builds
- Use ci_status_with_icon
- Don't describe symbols
- Remove all view related methods from Ci::Build and CommitStatus
- Remove unused Ci::Commit and Ci::Build methods
- Use polymorphism to render different types of CommitStatus
It's unclear how these blank values got added, but GitLab.com had a few:
```
irb(main):002:0> Note.where("line_code IS NOT NULL AND line_code = ''").count
=> 439
```
We've added a migration to convert any existing records to use a NULL
value when blank, and updated Note to set blank values to nil before
validation.
The OR condition for source_project_id/target_project_id leads to a
query plan that performs rather poorly on PostgreSQL due to the use of
sub-queries. Because Rails offers no easy alternative for this
particular problem we're forced to using a UNION for both conditions.
The resulting query performs much faster than just using an OR.
Previously this used a regular LIKE which is case-sensitive on
PostgreSQL. This ensures that for both PostgreSQL and MySQL the
searching is case-insensitive similar to searching for projects.
Similar to the changes made to Project.search the method
Project.search_by_title now also uses Arel so it can automatically use
ILIKE/LIKE instead of the lower() function.
This chance is broken up in two steps:
1. Use ILIKE on PostgreSQL and LIKE on MySQL, instead of using
"WHERE lower(x) LIKE lower(y)" as ILIKE is significantly faster than
using lower(). In many cases the use of lower() will force a slow
sequence scan.
2. Instead of using 1 query that searches both projects and namespaces
using a JOIN we're using 2 separate queries that are UNION'd
together. Using a JOIN would force a slow sequence scan, using a
UNION avoids this.
This method now uses Arel as Arel automatically uses ILIKE on PostgreSQL
and LIKE on MySQL, removing the need to handle this manually.
The methods used for this are Repository#tag_count and
Repository#branch_count which cache their output in Redis as well as
memoizing it in an instance variable. Both methods have a corresponding
methods/hooks to flush the caches at the right time.
These three tests were essentially checking that adding a note to
something updated its `noteable`'s `updated_at` attribute.
This is well-tested Rails behavior and we shouldn't feel the need to
write an integration test to verify it. At most we should be ensuring
that the association definition adds the `touch: true` option, which we
now do in Note's unit test.
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
Zeger-Jan van de Weg
Rémy Coutable
Timothy AndrewandRémy Coutable
Robert Speicher
Yorick Peterse
Robert Speicher
Dmitriy Zaporozhets
Kamil Trzcinski
ashleys
Douglas Barbosa Alexandre
tiagonbotelhoandYorick Peterse
Douwe Maan
Rubén Dávila