- 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 2 commits
-
-
Douwe Maan authored
-
Felipe Artur authored
-
- 20 Mar, 2016 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
- 17 Mar, 2016 3 commits
-
-
Douglas Barbosa Alexandre authored
-
Felipe Artur authored
-
Felipe Artur authored
-
- 16 Mar, 2016 1 commit
-
-
Felipe Artur authored
-
- 14 Mar, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 13 Mar, 2016 3 commits
-
-
Zeger-Jan van de Weg authored
Also incorporates the review into this, mainly spec changes.
-
Zeger-Jan van de Weg authored
The user has the rights of a public user execpt it can never create a project, group, or team. Also it cant view internal projects.
-
tiagonbotelho authored
-
- 12 Mar, 2016 4 commits
-
-
tiagonbotelho authored
-
tiagonbotelho authored
-
tiagonbotelho authored
-
Yorick Peterse authored
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.
-
- 11 Mar, 2016 2 commits
-
-
Yorick Peterse authored
We don't need the extra layer of nesting of UNION queries here (as User#authorized_projects already returns a UNION'd query).
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 10 Mar, 2016 3 commits
-
-
Felipe Artur authored
Prevent Groups to have smaller visibility than projects Add default_group_visibility_level to configuration Code improvements
-
Felipe Artur authored
-
Felipe Artur authored
-
- 07 Mar, 2016 1 commit
-
-
Rubén Dávila authored
-
- 05 Mar, 2016 1 commit
-
-
Robert Speicher authored
This was removed from the interface in https://github.com/gitlabhq/gitlabhq/pull/6027 but its implementation lingered around for two years.
-
- 20 Feb, 2016 2 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre 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.
-
- 04 Jan, 2016 1 commit
-
-
Valery Sizov authored
-
- 03 Dec, 2015 1 commit
-
-
Greg Smethells authored
-
- 20 Nov, 2015 1 commit
-
-
Yorick Peterse authored
These changes were added in GitLab EE commit d39de0ea91b26b8840195e5674b92c353cc16661. 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.
-
- 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
-
- 18 Nov, 2015 2 commits
-
-
Valery Sizov authored
-
Yorick Peterse authored
When getting the projects of a user we should get the public _and_ internal projects, not just the public ones.
-