BigW Consortium Gitlab

  1. 23 Nov, 2016 3 commits
  2. 18 Nov, 2016 1 commit
  3. 28 Oct, 2016 1 commit
    • Fix project member access for group links · db9979bc
      Sean McGivern authored
      `ProjectTeam#find_member` doesn't take group links into account. It was
      used in two places:
      
      1. An admin view - it can stay here.
      2. `ProjectTeam#member?`, which is often used to decide if a user has
         access to view something.
      
      This second part broke confidential issues viewing. `IssuesFinder` ends
      up delegating to `Project#authorized_for_user?`, which does consider
      group links, so users with access to the project via a group link could
      see confidential issues on the index page. However, `IssuesPolicy` used
      `ProjectTeam#member?`, so the same user couldn't view the issue when
      going to it directly.
  4. 28 Sep, 2016 1 commit
    • Allow Member.add_user to handle access requesters · ec0061a9
      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: 's avatarRémy Coutable <remy@rymai.me>
  5. 21 Sep, 2016 2 commits
  6. 20 Sep, 2016 3 commits
  7. 13 Sep, 2016 3 commits
  8. 18 Aug, 2016 1 commit
  9. 04 Aug, 2016 1 commit
  10. 02 Aug, 2016 1 commit
  11. 01 Aug, 2016 2 commits
  12. 29 Jul, 2016 2 commits
    • Implement review comments from @dbalexandre. · 7b2ad2d5
      Timothy Andrew authored
      1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
         `max_member_access`, which is a lot nicer.
      
      2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
         in migrations that don't need this module. Also remove comments where
         not necessary.
      
      3. Remove duplicate entry in CHANGELOG.
      
      4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.
      
      5. Split the `set_access_levels!` method in two - one each for `merge` and
         `push` access levels.
    • Admins count as masters too. · cc1cebdc
      Timothy Andrew authored
      1. In the context of protected branches.
      
      2. Test this behaviour.
  13. 27 Jul, 2016 1 commit
  14. 26 Jul, 2016 3 commits
  15. 22 Jul, 2016 1 commit
  16. 01 Jul, 2016 1 commit
  17. 29 Jun, 2016 1 commit
    • Reduce overhead and optimize ProjectTeam#max_member_access performance · e21c7d37
      Stan Hu authored
      The previous implementation would load the entire team member list and their
      respective attributes. Now we only search for the user's specific
      access level.
      
      In gitlab-com/operations#42, this reduces the overall overhead of rendering
      the issue from 28% to 20%.
      
      First step of optimizing #19273
  18. 16 Jun, 2016 2 commits
  19. 14 Jun, 2016 3 commits
  20. 13 Jun, 2016 1 commit
  21. 11 Mar, 2016 1 commit
  22. 18 Feb, 2016 1 commit
  23. 15 Oct, 2015 1 commit
    • Improve ProjectTeam#max_member_access performance · 3025b711
      Yorick Peterse authored
      By comparing objects in Ruby we can greatly improve the performance of
      this method. In the worst case (should no data be eager loaded) this
      will run the same amount of queries as before, in the best case (when
      data _is_ eager loadeD) it requires no queries at all.
      
      The added benchmark used to produce around 273 iterations per second.
      With this commit this has been increased to almost 40 000 iterations per
      second: a speedup of roughly 145 times.
      
      Combined with eager loading Note associations this results in about 30
      queries less when viewing a single issue, this in turn cuts down the
      loading time by 30-40%.
  24. 02 Oct, 2015 1 commit
  25. 14 Apr, 2015 2 commits