BigW Consortium Gitlab

  1. 24 Aug, 2017 1 commit
  2. 15 Jun, 2017 2 commits
    • Make the GroupFinder specs more strict · aeaf5860
      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.
    • Subgroups page should show groups authorized through inheritance · ef1811f4
      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
  3. 10 May, 2017 1 commit
  4. 08 Feb, 2017 1 commit
  5. 20 Mar, 2016 1 commit
  6. 17 Mar, 2016 1 commit
  7. 10 Mar, 2016 2 commits
  8. 04 Jan, 2016 1 commit
  9. 18 Nov, 2015 1 commit
    • Refactoed GroupsFinder into two separate classes · 2110247f
      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.
  10. 05 Nov, 2015 1 commit
  11. 05 Jun, 2014 1 commit