GitLab EE adds an extra relation that selects a "project_id" column
instead of an "id" column, making it very hard for this method to be
re-used in EE. Since using User#authorized_groups in
ProjectsFinder#all_groups apparently has no performance impact we can
just use it and keep everything compatible with EE.
Disallow blank (non-null) values for a Note's `line_code` attribute
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.
See merge request !3118
Fix responsive bug top navigation
Hi,
I have found and fixed a minor layout bug (responsive)
This is the situation before the fix:

And this is the situation after the fix:

See merge request !3190
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 class would be given a project ID which was then used to
retrieve the corresponding Project object. However, in all cases the
Project object was already known as it was used to grab the ID to pass
to ProjectSearchResults. By just passing a Project instead we remove the
need for an extra query as well as the need for some other complexity
in this class.
Instead of plucking IDs this class now uses ActiveRecord::Relation
objects. Plucking IDs is problematic as searching for projects can lead
to a huge amount of IDs being loaded into memory only to be used as an
argument for another query (instead of just using a sub-query).
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.
Improved search results filter dropdown
## Current
Currently filter dropdowns on search results page can be **very** long and off the page

## New
Changed over to the new dropdown

See merge request !3183
Added discard button to comment form
Also changed the labels on the buttons to better match the action they are completing.
Closes#8057
See merge request !3085
Add error for ajax:error when submitting comments
Fixes#13814

cc @dblessing
See merge request !2976