- 30 May, 2017 2 commits
-
-
Toon Claes authored
And use it in the API.
-
Toon Claes authored
The `starred` parameter couldn't be used in combination with `trending` or `non_public`. But this is changed now.
-
- 06 Apr, 2017 1 commit
-
-
Jacopo authored
Extended ProjectFinder in order to handle the following options: - current_user - which user use - project_ids_relation: int[] - project ids to use - params: - trending: boolean - non_public: boolean - starred: boolean - sort: string - visibility_level: int - tags: string[] - personal: boolean - search: string - non_archived: boolean GroupProjectsFinder now inherits from ProjectsFinder. Changed the code in order to use the new available options.
-
- 26 Jan, 2017 1 commit
-
-
Robert Speicher authored
-
- 28 Sep, 2016 1 commit
-
-
Rémy Coutable authored
Changes include: - Ensure Member.add_user is not called directly when not necessary - New GroupMember.add_users_to_group to have the same abstraction level as for Project - Refactor Member.add_user to take a source instead of an array of members - Fix Rubocop offenses - Always use Project#add_user instead of project.team.add_user - Factorize users addition as members in Member.add_users_to_source - Make access_level a keyword argument in GroupMember.add_users_to_group and ProjectMember.add_users_to_projects - Destroy any requester before adding them as a member - Improve the way we handle access requesters in Member.add_user Instead of removing the requester and creating a new member, we now simply accepts their access request. This way, they will receive a "access request granted" email. - Fix error that was previously silently ignored - Stop raising when access level is invalid in Member, let Rails validation do their work Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 15 Aug, 2016 2 commits
-
-
Ahmad Sherif authored
Follow-up 1003454c
-
Ahmad Sherif authored
Follow-up on 1003454c
-
- 21 Mar, 2016 1 commit
-
-
Douwe Maan authored
-
- 19 Mar, 2016 1 commit
-
-
Felipe Artur authored
-
- 12 Mar, 2016 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 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 1 commit
-
-
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.
-
- 07 Aug, 2015 1 commit
-
-
Robert Speicher authored
Encapsulates the logic for `Gitlab::Access::WHATEVER` levels.
-
- 12 Feb, 2015 1 commit
-
-
Jeroen van Baarsen authored
Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>
-
- 19 Mar, 2014 1 commit
-
-
Robert Speicher authored
-
- 25 Feb, 2014 2 commits
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Dmitriy Zaporozhets authored
Main purpose is move big amount of methods from user, group, project models and place filtering logic in one place. It also fixes 500 error on group page for PostgreSQL Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-