BigW Consortium Gitlab

  1. 03 May, 2017 1 commit
  2. 06 Apr, 2017 1 commit
  3. 24 Mar, 2017 1 commit
  4. 09 Mar, 2017 1 commit
  5. 06 Mar, 2017 1 commit
  6. 28 Feb, 2017 2 commits
  7. 24 Feb, 2017 1 commit
    • Don't allow deleting a ghost user. · 6fdb17cb
      Timothy Andrew authored
      - Add a `destroy_user` ability. This didn't exist before, and was implicit in
        other abilities (only admins could access the admin area, so only they could
        destroy all users; a user can only access their own account page, and so can
        destroy only themselves).
      
      - Grant this ability to admins, and when the current user is trying to destroy
        themselves. Disallow destroying ghost users in all cases.
      
      - Modify the `Users::DestroyService` to check this ability. Also check it in
        views to decide whether or not to show the "Delete User" button.
      
      - Add a short summary of the Ghost User to the bio.
  8. 15 Feb, 2017 1 commit
  9. 06 Feb, 2017 3 commits
  10. 24 Jan, 2017 1 commit
  11. 31 Dec, 2016 1 commit
  12. 29 Dec, 2016 1 commit
  13. 05 Dec, 2016 1 commit
  14. 02 Dec, 2016 1 commit
  15. 01 Nov, 2016 1 commit
  16. 02 Aug, 2016 1 commit
  17. 14 Jul, 2016 1 commit
  18. 08 Jul, 2016 2 commits
  19. 07 Jul, 2016 3 commits
  20. 30 Jun, 2016 1 commit
  21. 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>
  22. 16 Jun, 2016 2 commits
  23. 15 Jun, 2016 1 commit
  24. 14 Jun, 2016 1 commit
  25. 04 May, 2016 1 commit
  26. 20 Apr, 2016 1 commit
  27. 05 Apr, 2016 1 commit
    • Standardize the way we check for and display form errors · 7a2370f7
      Robert Speicher authored
      - Some views had a "Close" button. We've removed this, because we don't
        want users accidentally hiding the validation errors and not knowing
        what needs to be fixed.
      - Some views used `li`, some used `p`, some used `span`. We've
        standardized on `li`.
      - Some views only showed the first error. We've standardized on showing
        all of them.
      - Some views added an `#error_explanation` div, which we've made
        standard.
  28. 14 Mar, 2016 1 commit
  29. 13 Mar, 2016 2 commits
  30. 03 Mar, 2016 1 commit
  31. 28 Jan, 2016 1 commit
  32. 14 Jan, 2016 1 commit