- 01 Jul, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 16 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 13e37a3e.
-
James Lopez authored
-
- 15 Jun, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 14 Jun, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 16 May, 2016 2 commits
-
-
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).
-
Sean McGivern authored
- Don't do setup in spec bodies. - Don't `describe` a symbol. - Don't use 'should'.
-
- 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.
-
- 21 Mar, 2016 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Felipe Artur authored
-
- 19 Mar, 2016 1 commit
-
-
Felipe Artur authored
-
- 18 Mar, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 17 Mar, 2016 1 commit
-
-
Felipe Artur authored
-
- 12 Mar, 2016 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 10 Mar, 2016 2 commits
-
-
Felipe Artur authored
Prevent Groups to have smaller visibility than projects Add default_group_visibility_level to configuration Code improvements
-
Felipe Artur authored
-
- 08 Mar, 2016 1 commit
-
-
Robert Speicher authored
-
- 04 Jan, 2016 1 commit
-
-
Valery Sizov 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.
-
- 18 Nov, 2015 4 commits
-
-
Yorick Peterse authored
-
Yorick Peterse authored
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.
-
Yorick Peterse authored
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.
-
Yorick Peterse authored
-
- 05 Nov, 2015 1 commit
-
-
Valery Sizov authored
-
- 07 Oct, 2015 1 commit
-
-
Stan Hu authored
Closes #2619 Closes https://github.com/gitlabhq/gitlabhq/issues/9631
-
- 06 Oct, 2015 2 commits
-
-
Yorick Peterse authored
This changes the query to use a COUNT nested in an INNER JOIN, instead of a COUNT plus a GROUP BY. There are two reasons for this: 1. Using a COUNT in an INNER JOIN can be quite a bit faster. 2. The use of a GROUP BY means that method calls such as "any?" (and everything else that calls "count") operate on a Hash that counts the amount of notes on a per project basis, instead of just counting the total amount of projects. The query has been moved into Project.trending as its logic is simple enough. As a result of this testing the TrendingProjectsFinder class simply involves testing if the right methods are called, removing the need for setting up database records.
-
Yorick Peterse authored
-
- 07 Aug, 2015 1 commit
-
-
Robert Speicher authored
Encapsulates the logic for `Gitlab::Access::WHATEVER` levels.
-
- 27 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.
-
- 12 Feb, 2015 1 commit
-
-
Jeroen van Baarsen authored
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
-
- 05 Dec, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 24 Oct, 2014 1 commit
-
-
Valery Sizov authored
-
- 09 Oct, 2014 1 commit
-
-
Valery Sizov authored
-
- 28 Apr, 2014 3 commits
-
-
Jacob Vosmaer authored
-
Jacob Vosmaer authored
-
Jacob Vosmaer authored
-