- 16 May, 2016 1 commit
-
-
Sean McGivern authored
Before: we took the next milestone due across all projects in the search and found issues whose milestone title matched that one. Problems: 1. The milestone could be closed. 2. Different projects have milestones with different schedules. 3. Different projects have milestones with different titles. 4. Different projects can have milestones with different schedules, but the _same_ title. That means we could show issues from a past milestone, or one that's far in the future. After: gather the ID of the next milestone on each project we're looking at, and find issues with those milestone IDs. Problems: 1. For a lot of projects, this can return a lot of IDs. 2. The SQL query has to be different between Postgres and MySQL, because MySQL is much more lenient with HAVING: as well as the columns appearing in GROUP BY or in aggregate clauses, MySQL allows them to appear in the SELECT list (un-aggregated).
-
- 21 Apr, 2016 1 commit
-
-
Rémy Coutable authored
This is not needed anymore after !3815. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 20 Apr, 2016 7 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Mehmet Beydogan authored
Fix typos on sorting dropdown related to due date Remove constant array and add Structs on Issue to keep due date data to fill options
-
Mehmet Beydogan authored
Add due_date text field to sidebar issue#show Add ability sorting issues by due date ASC and DESC Add ability to filtering issues by No Due Date, Any Due Date, Due to tomorrow, Due in this week options Add handling issue due_date field for MergeRequest Update CHANGELOG Fix ambigous match for issues#show sidebar Fix SCREAMING_SNAKE_CASE offenses for due date contants Add specs for due date sorting and filtering on issues
-
Phil Hughes authored
Fixed issue with no label not working correctly
-
James Lopez authored
-
- 19 Apr, 2016 1 commit
-
-
James Lopez authored
-
- 13 Apr, 2016 1 commit
-
-
Yorick Peterse authored
This ensures that IssuableFinder returns a collection of unique issues, even when filtering issues using multiple labels.
-
- 29 Mar, 2016 2 commits
-
-
Phil Hughes authored
The frontend will then always use the name as the ID - like previous
-
Phil Hughes authored
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
-
- 21 Mar, 2016 1 commit
-
-
Douwe Maan authored
-
- 20 Mar, 2016 2 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
- 13 Mar, 2016 1 commit
-
-
tiagonbotelho authored
-
- 12 Mar, 2016 3 commits
-
-
tiagonbotelho authored
-
tiagonbotelho authored
-
tiagonbotelho authored
-
- 07 Mar, 2016 1 commit
-
-
Rubén Dávila authored
-
- 19 Feb, 2016 2 commits
- 18 Jan, 2016 1 commit
-
-
Yorick Peterse authored
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. Fixes gitlab-org/gitlab-ce#4071, gitlab-org/gitlab-ce#3707
-
- 07 Jan, 2016 1 commit
-
-
Yorick Peterse authored
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.
-
- 19 Nov, 2015 3 commits
-
-
Yorick Peterse authored
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.
-
Yorick Peterse authored
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.
-
Yorick Peterse authored
-
- 19 Oct, 2015 1 commit
-
-
Douwe Maan authored
-
- 16 Oct, 2015 3 commits
-
-
Douwe Maan authored
-
Zeger-Jan van de Weg authored
Credits to Douwe Maan
-
Zeger-Jan van de Weg authored
-
- 07 Oct, 2015 1 commit
-
-
Stan Hu authored
Closes #2619 Closes https://github.com/gitlabhq/gitlabhq/issues/9631
-
- 03 Oct, 2015 1 commit
-
-
Guilherme Garnier authored
-
- 07 Jul, 2015 2 commits
-
-
Robert Speicher authored
Also refactors IssuableFinder to avoid redundant title check.
-
Robert Speicher authored
-
- 19 Jun, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
Replaced: * "Accepted" with "Merged" * "Rejected" with "Closed" Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 27 May, 2015 1 commit
-
-
Douwe Maan authored
-
- 25 May, 2015 1 commit
-
-
Douwe Maan authored
-
- 30 Apr, 2015 1 commit
-
-
Dominik Sander authored
This groups milestones by title for issue views like it has been done for the milestone dashboard/project overview. Before milestones with the same title would show up multiple times in the filter dropdown and one could only filter per project and milestone. Now the milestone filter is based on the title of the milestone, i.e. all issues marked with the same milestone title are shown.
-