- 02 Aug, 2017 1 commit
-
-
Robert Speicher authored
-
- 15 Jun, 2017 2 commits
-
-
Toon Claes authored
Ensure the results match exactly and project authorizations do allow access to sibling groups/projects deeper down. Also apply WHERE scopes before running the UNION, to increase performance.
-
Toon Claes authored
When a user is authorized to a group, they are also authorized to see all the ancestor groups and descendant groups. When a user is authorized to a project, they are authorized to see all the ancestor groups too. Closes #32135 See merge request !11764
-
- 10 May, 2017 1 commit
-
-
Douwe Maan authored
Use GroupsFinder to find subgroups the user has access to See merge request !2096
-
- 18 Mar, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 17 Mar, 2016 1 commit
-
-
Felipe Artur authored
-
- 10 Mar, 2016 1 commit
-
-
Felipe Artur authored
-
- 04 Jan, 2016 1 commit
-
-
Valery Sizov authored
-
- 18 Nov, 2015 2 commits
-
-
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
-