Added back upcoming to milestone filter
Fixed bug that would cause the currently selected value to disappear on filters
Fixed bug that throw an error when filtering by upcoming when there is only a milestone in the past
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
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.
When using IssuableFinder with a Group we can greatly reduce the amount
of projects operated on (due to not including all public/internal
projects) by simply passing it down to the ProjectsFinder class.
This reduces the timings of the involved queries from roughly 300
ms to roughly 20 ms.
Fixesgitlab-org/gitlab-ce#4071, gitlab-org/gitlab-ce#3707
When grabbing the projects to filter issues by we don't care about the
order they're returned in. By removing the ORDER BY the resulting query
can be quite a bit faster.
These changes were added in GitLab EE commit
d39de0ea91. The tests were a bit bugged
(they used a non existing group, thus not testing a crucial part) which
I only noticed when porting CE changes to EE.
Award Emoji
This it first iteration of award emoji feature.
We have plan to extend emoji picker by the next release.
For now, you can add award by clicking to the emoji picker or posting a regular comment with emoji like "👍" and any other. You can post not only emoji that listed in the emoji picker.
See merge request !1825
When using IssuableFinder/IssuesFinder to find issues for multiple
projects it's more efficient to use a JOIN + a "WHERE project_id IN"
condition opposed to running a sub-query.
This change means that when finding issues without labels we're now
using the following SQL:
SELECT issues.*
FROM issues
JOIN projects ON projects.id = issues.project_id
LEFT JOIN label_links ON label_links.target_type = 'Issue'
AND label_links.target_id = issues.id
WHERE (
projects.id IN (...)
OR projects.visibility_level IN (20, 10)
)
AND issues.state IN ('opened','reopened')
AND label_links.id IS NULL
ORDER BY issues.id DESC;
instead of:
SELECT issues.*
FROM issues
LEFT JOIN label_links ON label_links.target_type = 'Issue'
AND label_links.target_id = issues.id
WHERE issues.project_id IN (
SELECT id
FROM projects
WHERE id IN (...)
OR visibility_level IN (20,10)
)
AND issues.state IN ('opened','reopened')
AND label_links.id IS NULL
ORDER BY issues.id DESC;
The big benefit here is that in the last case PostgreSQL can't properly
use all available indexes. In particular it ends up performing a
sequence scan on the "label_links" table (processing around 290 000
rows). The new query is roughly 2x as fast as the old query.
Since this method's returned data doesn't change between calls on the
same IssuableFinder instance we can just memoize this similar to the
"project" method.
This class now uses a UNION (when needed) instead of plucking tens of
thousands of project IDs into memory. The tests have also been
re-written to ensure all different use cases are tested properly
(assuming I didn't forget any cases).
The finder has also been broken up into 3 different finder classes:
* ContributedProjectsFinder: class for getting the projects a user
contributed to.
* PersonalProjectsFinder: class for getting the personal projects of a
user.
* ProjectsFinder: class for getting generic projects visible to a given
user.
Previously a lot of the logic of these finders was handled directly in
the users controller.
In the previous setup the GroupsFinder class had two distinct tasks:
1. Finding the projects user A could see
2. Finding the projects of user A that user B could see
Task two was actually handled outside of the GroupsFinder (in the
UsersController) by restricting the returned list of groups to those the
viewed user was a member of. Moving all this logic into a single finder
proved to be far too complex and confusing, hence there are now two
finders:
* GroupsFinder: for finding groups a user can see
* JoinedGroupsFinder: for finding groups that user A is a member of,
restricted to either public groups or groups user B can also see.
Phil Hughes
Douwe Maan
Felipe Artur
Douglas Barbosa Alexandre
Zeger-Jan van de Weg
Dmitriy Zaporozhets
tiagonbotelho
Yorick Peterse
Rubén Dávila
Tap
Valery Sizov
Greg Smethells