1. 22 Feb, 2019 1 commit
  2. 21 Feb, 2019 2 commits
  3. 14 Jan, 2019 1 commit
  4. 31 Dec, 2018 1 commit
  5. 30 Nov, 2018 1 commit
    • Sean McGivern's avatar
      Add a flag to use a subquery for group issues search · 7fd5dbf9
      Sean McGivern authored
      We already had a flag to use a CTE, but this broke searching in some
      cases where we need to sort by a joined table. Disabling the CTE flag
      makes searches much slower.
      
      The new flag, to use a subquery, makes them slightly slower than the
      CTE, while maintaining correctness. If both it and the CTE flag are
      enabled, the subquery takes precedence.
      7fd5dbf9
  6. 23 Nov, 2018 1 commit
    • Jacopo's avatar
      Filter by `None`/`Any` for labels in issues/mrs API · c068ac67
      Jacopo authored
      By using the parameters `?labels=None|Any` the user can filter
      issues/mrs from the API that has `none/any` label.
      
      Affected endpoints are:
      
      - /api/issues
      - /api/projects/:id/issues
      - /api/groups/:id/issues
      - /api/merge_requests
      - /api/projects/:id/merge_requests
      - /api/groups/:id/merge_requests
      c068ac67
  7. 01 Nov, 2018 2 commits
  8. 26 Oct, 2018 2 commits
  9. 03 Oct, 2018 1 commit
  10. 01 Oct, 2018 1 commit
  11. 11 Jul, 2018 1 commit
  12. 21 May, 2018 1 commit
  13. 05 Mar, 2018 1 commit
  14. 01 Feb, 2018 1 commit
  15. 22 Dec, 2017 1 commit
  16. 05 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Re-use issue/MR counts for the pagination system · 42062a45
      Yorick Peterse authored
      This changes the issue and MR index pages so the pagination system
      re-uses the output of the COUNT(*) query used to calculate the number of
      rows per state (opened, closed, etc). This removes the need for an
      additional COUNT(*) on both pages.
      42062a45
  17. 30 Aug, 2017 1 commit
  18. 02 Aug, 2017 1 commit
  19. 07 Jul, 2017 1 commit
  20. 30 Jun, 2017 2 commits
    • Sean McGivern's avatar
      0c6cdd07
    • Sean McGivern's avatar
      Only do complicated confidentiality checks when necessary · 42ccb598
      Sean McGivern authored
      When we are filtering by a single project, and the current user has access to
      see confidential issues on that project, we don't need to filter by
      confidentiality at all - just as if the user were an admin.
      
      The filter by confidentiality often picks a non-optimal query plan: for
      instance, AND-ing the results of all issues in the project (a relatively small
      set), and all issues in the states requested (a huge set), rather than just
      starting small and winnowing further.
      42ccb598
  21. 19 Jun, 2017 1 commit
  22. 14 Jun, 2017 1 commit
  23. 05 May, 2017 1 commit
  24. 04 May, 2017 1 commit
  25. 01 May, 2017 1 commit
  26. 26 Apr, 2017 1 commit
  27. 03 Apr, 2017 1 commit
  28. 15 Mar, 2017 1 commit
  29. 17 Feb, 2017 1 commit
  30. 05 Feb, 2017 1 commit
  31. 15 Dec, 2016 1 commit
  32. 06 Dec, 2016 1 commit
  33. 20 Sep, 2016 1 commit
  34. 03 Jun, 2016 2 commits
  35. 16 May, 2016 1 commit
    • Sean McGivern's avatar
      Make upcoming milestone work across projects · 750b2ff0
      Sean McGivern authored
      Before: we took the next milestone due across all projects in the
      search and found issues whose milestone title matched that
      one. Problems:
      
      1. The milestone could be closed.
      2. Different projects have milestones with different schedules.
      3. Different projects have milestones with different titles.
      4. Different projects can have milestones with different schedules, but
         the _same_ title. That means we could show issues from a past
         milestone, or one that's far in the future.
      
      After: gather the ID of the next milestone on each project we're looking
      at, and find issues with those milestone IDs. Problems:
      
      1. For a lot of projects, this can return a lot of IDs.
      2. The SQL query has to be different between Postgres and MySQL, because
         MySQL is much more lenient with HAVING: as well as the columns
         appearing in GROUP BY or in aggregate clauses, MySQL allows them to
         appear in the SELECT list (un-aggregated).
      750b2ff0