| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Prevent Groups to have smaller visibility than projects
Add default_group_visibility_level to configuration
Code improvements
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
Label" filters
Closes #2619
Closes https://github.com/gitlabhq/gitlabhq/issues/9631
|
|
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.
|
|
|
|
Encapsulates the logic for `Gitlab::Access::WHATEVER` levels.
|
|
filter active.
|
|
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.
|
|
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Speed up features/notes_on_merge_requests_spec
|
|
|
|
Uses the :simple merge request factory trait introduced by d166e70; cuts
execution time of this spec in half.
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
