An error occurred fetching the project authors.
  1. 06 Apr, 2017 1 commit
  2. 21 Mar, 2017 1 commit
  3. 06 Mar, 2017 1 commit
  4. 02 Mar, 2017 2 commits
  5. 23 Feb, 2017 4 commits
  6. 20 Feb, 2017 1 commit
    • Z.J. van de Weg's avatar
      Transactional mattermost team creation · 444d71e0
      Z.J. van de Weg authored
      Before this commit, but still on this feature branch, the creation of
      mattermost teams where a background job. However, it was decided it was
      better that these happened as transaction so feedback could be displayed
      to the user.
      444d71e0
  7. 16 Feb, 2017 1 commit
  8. 13 Feb, 2017 1 commit
  9. 10 Feb, 2017 1 commit
  10. 07 Feb, 2017 1 commit
    • Yorick Peterse's avatar
      Refresh authorizations when transferring projects · ebae3839
      Yorick Peterse authored
      This ensures that project authorizations are refreshed when moving a
      project from one namespace to another. When doing so the permissions for
      all users of both the old and new namespaces are refreshed.
      
      See #26194 for more information.
      ebae3839
  11. 02 Feb, 2017 1 commit
  12. 13 Jan, 2017 1 commit
  13. 03 Jan, 2017 1 commit
  14. 28 Dec, 2016 1 commit
  15. 26 Dec, 2016 1 commit
  16. 21 Dec, 2016 1 commit
    • Markus Koller's avatar
      Add more storage statistics · 3ef4f74b
      Markus Koller authored
      This adds counters for build artifacts and LFS objects, and moves
      the preexisting repository_size and commit_count from the projects
      table into a new project_statistics table.
      
      The counters are displayed in the administration area for projects
      and groups, and also available through the API for admins (on */all)
      and normal users (on */owned)
      
      The statistics are updated through ProjectCacheWorker, which can now
      do more granular updates with the new :statistics argument.
      3ef4f74b
  17. 13 Dec, 2016 1 commit
  18. 23 Nov, 2016 2 commits
  19. 18 Nov, 2016 1 commit
  20. 27 Oct, 2016 1 commit
  21. 24 Oct, 2016 2 commits
  22. 21 Oct, 2016 1 commit
  23. 19 Oct, 2016 1 commit
  24. 28 Sep, 2016 1 commit
    • Rémy Coutable's avatar
      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: default avatarRémy Coutable <remy@rymai.me>
      ec0061a9
  25. 22 Sep, 2016 3 commits
  26. 15 Sep, 2016 1 commit
  27. 18 Aug, 2016 1 commit
  28. 02 Aug, 2016 1 commit
  29. 05 Jul, 2016 1 commit
  30. 01 Jul, 2016 1 commit
  31. 24 Jun, 2016 1 commit
    • Rémy Coutable's avatar
      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: default avatarRémy Coutable <remy@rymai.me>
      aec3475d
  32. 16 Jun, 2016 1 commit