BigW Consortium Gitlab

  1. 21 Apr, 2017 1 commit
  2. 31 Mar, 2017 1 commit
    • Eliminate unnecessary queries that add ~500 ms of load time for a large issue · ced1bbab
      Stan Hu authored
      Looking at the SQL log, we see useless queries such as:
      
      ```
      D, [2017-03-22T03:25:00.726710 #2629] DEBUG -- :    (235.9ms)  SELECT MAX("project_authorizations"."access_level") AS maximum_access_level, "project_authorizations"."user_id" AS project_authorizations_user_id FROM "project_authorizations" WHERE "project_authorizations"."project_id" = 13083 AND 1=0 GROUP BY "project_authorizations"."user_id"  [["project_id", 13083]]
      ```
  3. 23 Feb, 2017 2 commits
  4. 23 Nov, 2016 3 commits
  5. 18 Nov, 2016 1 commit
  6. 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.
  7. 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>
  8. 21 Sep, 2016 2 commits
  9. 20 Sep, 2016 3 commits
  10. 13 Sep, 2016 3 commits
  11. 18 Aug, 2016 1 commit
  12. 04 Aug, 2016 1 commit
  13. 02 Aug, 2016 1 commit
  14. 01 Aug, 2016 2 commits
  15. 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.
  16. 27 Jul, 2016 1 commit
  17. 26 Jul, 2016 3 commits
  18. 22 Jul, 2016 1 commit
  19. 01 Jul, 2016 1 commit
  20. 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
  21. 16 Jun, 2016 2 commits
  22. 14 Jun, 2016 3 commits
  23. 13 Jun, 2016 1 commit
  24. 11 Mar, 2016 1 commit
  25. 18 Feb, 2016 1 commit