BigW Consortium Gitlab

  1. 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>
  2. 22 Sep, 2016 3 commits
  3. 15 Sep, 2016 1 commit
  4. 18 Aug, 2016 1 commit
  5. 02 Aug, 2016 1 commit
  6. 05 Jul, 2016 1 commit
  7. 01 Jul, 2016 1 commit
  8. 24 Jun, 2016 1 commit
    • Fix an information disclosure when requesting access to a group containing private projects · aec3475d
      Rémy Coutable authored
      The issue was with the `User#groups` and `User#projects` associations
      which goes through the `User#group_members` and `User#project_members`.
      
      Initially I chose to use a secure approach by storing the requester's
      user ID in `Member#created_by_id` instead of `Member#user_id` because I
      was aware that there was a security risk since I didn't know the
      codebase well enough.
      
      Then during the review, we decided to change that and directly store the
      requester's user ID into `Member#user_id` (for the sake of simplifying
      the code I believe), meaning that every `group_members` / `project_members`
      association would include the requesters by default...
      
      My bad for not checking that all the `group_members` / `project_members`
      associations and the ones that go through them (e.g. `Group#users` and
      `Project#users`) were made safe with the `where(requested_at: nil)` /
      `where(members: { requested_at: nil })` scopes.
      
      Now they are all secure.
      Signed-off-by: 's avatarRémy Coutable <remy@rymai.me>
  9. 16 Jun, 2016 3 commits
  10. 14 Jun, 2016 3 commits
  11. 03 Jun, 2016 2 commits
  12. 09 May, 2016 1 commit
    • Remove the annotate gem and delete old annotations · f1479b56
      Jeroen van Baarsen authored
      In 8278b763 the default behaviour of annotation
      has changes, which was causing a lot of noise in diffs. We decided in #17382
      that it is better to get rid of the whole annotate gem, and instead let people
      look at schema.rb for the columns in a table.
      
      Fixes: #17382
  13. 06 May, 2016 1 commit
  14. 19 Apr, 2016 1 commit
  15. 30 Mar, 2016 1 commit
  16. 21 Mar, 2016 1 commit
  17. 20 Mar, 2016 1 commit
  18. 18 Mar, 2016 1 commit
  19. 11 Mar, 2016 3 commits
  20. 10 Mar, 2016 3 commits
  21. 22 Jan, 2016 1 commit
  22. 20 Jan, 2016 1 commit
  23. 06 Jan, 2016 1 commit
  24. 04 Jan, 2016 1 commit
  25. 18 Nov, 2015 1 commit
  26. 17 Nov, 2015 1 commit
  27. 13 Nov, 2015 1 commit
  28. 11 Nov, 2015 1 commit
  29. 05 Nov, 2015 1 commit