An error occurred fetching the project authors.
  1. 12 Jun, 2013 1 commit
  2. 06 Jun, 2013 2 commits
  3. 04 Jun, 2013 1 commit
  4. 03 Jun, 2013 2 commits
  5. 23 May, 2013 1 commit
  6. 14 May, 2013 1 commit
  7. 06 May, 2013 2 commits
  8. 03 Apr, 2013 1 commit
  9. 01 Apr, 2013 1 commit
  10. 25 Mar, 2013 1 commit
  11. 18 Mar, 2013 1 commit
  12. 07 Mar, 2013 1 commit
  13. 05 Mar, 2013 4 commits
  14. 01 Mar, 2013 2 commits
  15. 27 Feb, 2013 4 commits
  16. 20 Feb, 2013 1 commit
  17. 16 Feb, 2013 1 commit
    • Sebastian Ziebell's avatar
      API: fixes visibility of project hook · e9d3b965
      Sebastian Ziebell authored
      When a user is not authorized to see the list of hooks for a project, he is
      still able to access the hooks separately. For example if access to
      `GET /projects/:id/hooks` fails and returns a `403 Unauthorized` error it is
      still possible to access a hook directly via `GET /projects/:id/hooks/:hook_id`.
      
      Fixes access, also added tests to check access and status codes of hooks.
      e9d3b965
  18. 14 Feb, 2013 4 commits
  19. 13 Feb, 2013 3 commits
  20. 12 Feb, 2013 1 commit
    • Sebastian Ziebell's avatar
      API: changed status codes for project hooks functions · 7cc4339f
      Sebastian Ziebell authored
      Different status codes in the API lib are returned on hook creation, update or deletion.
      If a required parameter is not given (e.g. `url` in `/projects/:id/hooks/:hook_id`) status
      code 400 (Bad request) is returned. On hook deletion a 200 status code is returned, regardless if
      the hook is present or not. This makes the DELETE function an idempotent operation. Appropriate tests
      are added to check these status codes.
      7cc4339f
  21. 09 Feb, 2013 1 commit
  22. 08 Feb, 2013 3 commits
  23. 01 Feb, 2013 1 commit
    • Felix Gilcher's avatar
      Don't crash when removing a user that's not project member · ce6436b9
      Felix Gilcher authored
      The attempt to revoke project access for a user that was not member of the
      project results in a 500 Internal Server error where it actually should
      result in a 200 OK since after the operation, the user is not member of
      the project. This turns the operation into an idempotent call that can
      be repeated with no ill effects.
      
      Updated the spec and changed the code accordingly. However, the result differs
      slightly, as we can't return the users project access level if the user was not
      member. I'm not aware if anybody relies on the result of this call.
      
      Fixes #2832
      ce6436b9