1. 03 Oct, 2016 2 commits
  2. 22 Sep, 2016 5 commits
  3. 20 Sep, 2016 1 commit
  4. 19 Sep, 2016 2 commits
  5. 10 Sep, 2016 1 commit
  6. 08 Sep, 2016 3 commits
  7. 02 Sep, 2016 1 commit
  8. 31 Aug, 2016 1 commit
  9. 30 Aug, 2016 1 commit
  10. 28 Aug, 2016 1 commit
  11. 18 Aug, 2016 1 commit
    • Sean McGivern's avatar
      Handle legacy sort order values · ea482a5acc1e
      Sean McGivern authored
      The sort orders used to be id_asc / id_desc, and are now created_asc /
      created_desc. Users can still have cookies containing the old sort
      orders, or bookmarks to links specifying them, so convert these to the
      new versions quietly.
      ea482a5acc1e
  12. 15 Aug, 2016 3 commits
  13. 03 Aug, 2016 2 commits
  14. 02 Aug, 2016 1 commit
  15. 01 Aug, 2016 1 commit
    • zs's avatar
      State specific default sort order for issuables · cb4c5d66724c
      zs authored
      Provide more sensible default sort order for issues and merge requests
      based on the following table:
      
      | type           | state  | default sort order |
      |----------------|--------|--------------------|
      | issues         | open   | last created       |
      | issues         | closed | last updated       |
      | issues         | all    | last created       |
      | merge requests | open   | last created       |
      | merge requests | merged | last updated       |
      | merge requests | closed | last updated       |
      | merge requests | all    | last created       |
      cb4c5d66724c
  16. 29 Jul, 2016 1 commit
    • Lin Jen-Shin's avatar
      Add pipeline_events to Slack service: · 5c1405d17059
      Lin Jen-Shin authored
      Also add Service#event_names so that we don't have to hard code all
      event names in ServiceParams. Note that I don't know why we want to
      call plural on issue_event and merge_request_event so that we still
      need to hard code them for issues_event and merge_requests_event.
      See app/helpers/services_helper.rb for those special rules.
      5c1405d17059
  17. 20 Jul, 2016 1 commit
  18. 19 Jul, 2016 1 commit
  19. 18 Jul, 2016 1 commit
  20. 14 Jul, 2016 2 commits
    • Timothy Andrew's avatar
      Use a single challenge for U2F authentication. · 7d2bbd1c738e
      Timothy Andrew authored
      1. According to the spec, either we have a single challenge with
         a number of `signRequests`, or a number of `signRequests`, each with
         it's own challenge.
      
      2. Previously, we had both these - per-request challenges, as well as a
         single extra challenge.
      
      3. This commit changes this so that the per-request challenges are
         removed, leaving only a single challenge, as per the v1.1 U2F API.
      
      4. The existing implementation didn't work in Firefox, because the
         Firefox (extension) implementation is less flexible with regard to
         the inputs.
      
      5. Fix teaspoon specs.
      
      6. References: https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#h2_background
      7d2bbd1c738e
    • Timothy Andrew's avatar
      Load Javascript U2F library selectively. · ed5dfdd6ba5d
      Timothy Andrew authored
      1. Only on supported Chrome versions
      
      2. Mainly, this lets us simplify the javascript-based U2F check to
         `window.u2f`, where `window.u2f` can either be loaded from the GitLab
         server (for Chrome) or from the Firefox extension.
      
      3. This is a better way to provide browser detection for U2F.
      ed5dfdd6ba5d
  21. 12 Jul, 2016 8 commits