BigW Consortium Gitlab

  1. 17 Feb, 2017 1 commit
    • Todo done clicking is kind of unusable. · 26160459
      Jacopo authored
      The Done button will change to an Undo button and the line item will be greyed out.
      Bold links will be unbolded.
      The user can undo the task by clicking the Undo button.
  2. 13 Feb, 2017 1 commit
  3. 08 Feb, 2017 1 commit
  4. 03 Feb, 2017 1 commit
  5. 16 Jan, 2017 1 commit
    • Speed up dashboard milestone index by scoping IssuesFinder to user authorized projects · cf3be218
      Adam Niedzielski authored
      It improves performance in dashboard milestone index page by passing a
      hint to "IssuesFinder". "IssuesFinder" generates a more performant query
      when it is limited to authorized projects for user.
      In the dashboard we already limit the projects to these authorized for
      user (see "Dashboard::ApplicationController#projects"), so we can safely
      pass this option to "IssuesFinder".
  6. 06 Jan, 2017 1 commit
  7. 23 Dec, 2016 1 commit
  8. 21 Dec, 2016 2 commits
  9. 11 Nov, 2016 2 commits
  10. 19 Oct, 2016 3 commits
  11. 19 Aug, 2016 1 commit
  12. 18 Aug, 2016 3 commits
  13. 12 Aug, 2016 1 commit
    • Recover usage of Todos counter cache · f8b53ba2
      Paco Guzman authored
      We’re being kept up to date the counter data but we’re not using it.
      The only thing which is not real if is the number of projects that the 
      user read changes the number of todos can be stale for some time.
      
      The counters will be sync just after the user receives a new todo or mark any as done
  14. 12 Jul, 2016 1 commit
  15. 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>
  16. 17 Jun, 2016 2 commits
  17. 03 Jun, 2016 2 commits
  18. 10 May, 2016 1 commit
    • Restrict starred projects to viewable ones · 97424ea5
      Sean McGivern authored
      `User#starred_projects` doesn't perform any visibility checks. This has
      a couple of problems:
      
      1. It assumes a user can always view all of their starred projects in
         perpetuity (project not changed to private, access revoked, etc.).
      2. It assumes that we'll only ever allow a user to star a project they
         can view. This is currently the case, but bugs happen.
      
      Add `User#viewable_starred_projects` to filter the starred projects by
      those the user either has explicit access to, or are public or
      internal. Then use that in all places where we list the user's starred
      projects.
  19. 03 May, 2016 1 commit
  20. 01 Apr, 2016 1 commit
  21. 30 Mar, 2016 1 commit
  22. 23 Mar, 2016 3 commits
  23. 19 Mar, 2016 1 commit
  24. 18 Mar, 2016 1 commit
  25. 17 Mar, 2016 3 commits
  26. 16 Mar, 2016 1 commit
  27. 10 Mar, 2016 1 commit
  28. 04 Mar, 2016 1 commit