BigW Consortium Gitlab

  1. 05 Sep, 2017 1 commit
    • 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.
  2. 30 Aug, 2017 1 commit
  3. 02 Aug, 2017 1 commit
  4. 07 Jul, 2017 1 commit
  5. 30 Jun, 2017 2 commits
    • 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.
  6. 18 Jun, 2017 1 commit
  7. 14 Jun, 2017 1 commit
  8. 05 May, 2017 1 commit
  9. 04 May, 2017 1 commit
  10. 01 May, 2017 1 commit
  11. 26 Apr, 2017 1 commit
  12. 03 Apr, 2017 1 commit
  13. 15 Mar, 2017 1 commit
  14. 17 Feb, 2017 1 commit
  15. 05 Feb, 2017 1 commit
  16. 15 Dec, 2016 1 commit
  17. 06 Dec, 2016 1 commit
  18. 20 Sep, 2016 1 commit
  19. 03 Jun, 2016 2 commits
  20. 16 May, 2016 2 commits
    • 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).
    • Tidy up IssuesFinder specs · 91480e5e
      Sean McGivern authored
      - Don't do setup in spec bodies.
      - Don't `describe` a symbol.
      - Don't use 'should'.
  21. 13 Apr, 2016 1 commit
  22. 07 Oct, 2015 1 commit
  23. 27 May, 2015 1 commit
  24. 30 Apr, 2015 1 commit
    • Group milestones by title in the dashboard and all other issue views · e6ee8d0e
      Dominik Sander authored
      This groups milestones by title for issue views like it has been done for
      the milestone dashboard/project overview. Before milestones with the
      same title would show up multiple times in the filter dropdown and one could
      only filter per project and milestone. Now the milestone filter is based
      on the title of the milestone, i.e. all issues marked with the same
      milestone title are shown.
  25. 12 Feb, 2015 1 commit
  26. 05 Dec, 2014 1 commit
  27. 25 Feb, 2014 1 commit
  28. 10 Feb, 2014 1 commit
  29. 15 Jan, 2014 1 commit
  30. 25 Dec, 2013 1 commit
  31. 08 Aug, 2013 1 commit
  32. 18 Jul, 2013 2 commits
    • Rebase on master · 09112dbb
      Izaak Alpert authored
      Trying to retrigger travis
      Change-Id: Ifd86fb4c6b2791ad176230254fbf69a9ade979fb
    • Merge Request on forked projects · 3d7194f0
      Izaak Alpert authored
      The good:
      
       - You can do a merge request for a forked commit and it will merge properly (i.e. it does work).
       - Push events take into account merge requests on forked projects
       - Tests around merge_actions now present, spinach, and other rspec tests
       - Satellites now clean themselves up rather then recreate
      
      The questionable:
      
       - Events only know about target projects
       - Project's merge requests only hold on to MR's where they are the target
       - All operations performed in the satellite
      
      The bad:
      
        -  Duplication between project's repositories and satellites (e.g. commits_between)
      
      (for reference: http://feedback.gitlab.com/forums/176466-general/suggestions/3456722-merge-requests-between-projects-repos)
      
      Fixes:
      
      Make test repos/satellites only create when needed
      -Spinach/Rspec now only initialize test directory, and setup stubs (things that are relatively cheap)
      -project_with_code, source_project_with_code, and target_project_with_code now create/destroy their repos individually
      -fixed remote removal
      -How to merge renders properly
      -Update emails to show project/branches
      -Edit MR doesn't set target branch
      -Fix some failures on editing/creating merge requests, added a test
      -Added back a test around merge request observer
      -Clean up project_transfer_spec, Remove duplicate enable/disable observers
      -Ensure satellite lock files are cleaned up, Attempted to add some testing around these as well
      -Signifant speed ups for tests
      -Update formatting ordering in notes_on_merge_requests
      -Remove wiki schema update
      Fixes for search/search results
      -Search results was using by_project for a list of projects, updated this to use in_projects
      -updated search results to reference the correct (target) project
      -udpated search results to print both sides of the merge request
      
      Change-Id: I19407990a0950945cc95d62089cbcc6262dab1a8