BigW Consortium Gitlab

  1. 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'.
  2. 13 Apr, 2016 1 commit
  3. 21 Mar, 2016 3 commits
  4. 19 Mar, 2016 1 commit
  5. 18 Mar, 2016 1 commit
  6. 17 Mar, 2016 1 commit
  7. 12 Mar, 2016 1 commit
  8. 10 Mar, 2016 2 commits
  9. 08 Mar, 2016 1 commit
  10. 04 Jan, 2016 1 commit
  11. 20 Nov, 2015 1 commit
    • Port GitLab EE ProjectsFinder changes · fed059a1
      Yorick Peterse authored
      These changes were added in GitLab EE commit
      d39de0ea91b26b8840195e5674b92c353cc16661. The tests were a bit bugged
      (they used a non existing group, thus not testing a crucial part) which
      I only noticed when porting CE changes to EE.
  12. 18 Nov, 2015 4 commits
    • Refactor ProjectsFinder to not pluck IDs · fbcf3bd3
      Yorick Peterse authored
      This class now uses a UNION (when needed) instead of plucking tens of
      thousands of project IDs into memory. The tests have also been
      re-written to ensure all different use cases are tested properly
      (assuming I didn't forget any cases).
      
      The finder has also been broken up into 3 different finder classes:
      
      * ContributedProjectsFinder: class for getting the projects a user
        contributed to.
      * PersonalProjectsFinder: class for getting the personal projects of a
        user.
      * ProjectsFinder: class for getting generic projects visible to a given
        user.
      
      Previously a lot of the logic of these finders was handled directly in
      the users controller.
    • Refactoed GroupsFinder into two separate classes · 2110247f
      Yorick Peterse authored
      In the previous setup the GroupsFinder class had two distinct tasks:
      
      1. Finding the projects user A could see
      2. Finding the projects of user A that user B could see
      
      Task two was actually handled outside of the GroupsFinder (in the
      UsersController) by restricting the returned list of groups to those the
      viewed user was a member of. Moving all this logic into a single finder
      proved to be far too complex and confusing, hence there are now two
      finders:
      
      * GroupsFinder: for finding groups a user can see
      * JoinedGroupsFinder: for finding groups that user A is a member of,
        restricted to either public groups or groups user B can also see.
  13. 05 Nov, 2015 1 commit
  14. 07 Oct, 2015 1 commit
  15. 06 Oct, 2015 2 commits
    • Revamp trending projects query · b7abba0c
      Yorick Peterse authored
      This changes the query to use a COUNT nested in an INNER JOIN, instead
      of a COUNT plus a GROUP BY. There are two reasons for this:
      
      1. Using a COUNT in an INNER JOIN can be quite a bit faster.
      2. The use of a GROUP BY means that method calls such as "any?"
         (and everything else that calls "count") operate on a Hash that
         counts the amount of notes on a per project basis, instead of just
         counting the total amount of projects.
      
      The query has been moved into Project.trending as its logic is simple
      enough. As a result of this testing the TrendingProjectsFinder class
      simply involves testing if the right methods are called, removing the
      need for setting up database records.
    • Added specs for TrendingProjectsFinder · 1f14e689
      Yorick Peterse authored
  16. 07 Aug, 2015 1 commit
  17. 27 May, 2015 1 commit
  18. 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.
  19. 12 Feb, 2015 1 commit
  20. 05 Dec, 2014 1 commit
  21. 24 Oct, 2014 1 commit
  22. 09 Oct, 2014 1 commit
  23. 28 Apr, 2014 6 commits
  24. 03 Apr, 2014 1 commit
  25. 19 Mar, 2014 2 commits
  26. 25 Feb, 2014 1 commit