BigW Consortium Gitlab

  1. 09 Sep, 2016 1 commit
  2. 07 Sep, 2016 1 commit
  3. 31 Aug, 2016 1 commit
  4. 19 Aug, 2016 1 commit
  5. 18 Aug, 2016 1 commit
  6. 17 Aug, 2016 1 commit
  7. 15 Aug, 2016 2 commits
  8. 09 Aug, 2016 1 commit
  9. 02 Aug, 2016 1 commit
  10. 01 Aug, 2016 1 commit
  11. 28 Jul, 2016 1 commit
    • Fix the title of the toggle dropdown button · 94e6d51e
      Herminio Torres authored
      Before when you choose the way of `sort` instead it display the title correctly it was just apply the humanize helper in sort value.
      
      E.g.
      
      When you choose `Last updated` it should display the title `Last updated` instead of `Recently updated`. This fix makes this correctly displays the title.
      
      Change the implementation of the `link_to` `filter_branches_path`
      
      - Change the value of the `params[:sort]` in `link_to`. E.g. instead of using `'recently_updated'` is now using `sort_value_recently_updated`.
      
      - Change the values of the case in the `branches_sorted_by` method for the values it receives in the `params[:sort]` that are: `nil`, `'name'`, `'updated_desc'`, `'updated_asc'`.
  12. 26 Jul, 2016 1 commit
  13. 19 Jul, 2016 2 commits
  14. 12 Jul, 2016 1 commit
  15. 01 Jul, 2016 1 commit
  16. 16 Jun, 2016 2 commits
  17. 15 Jun, 2016 1 commit
  18. 14 Jun, 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. 21 Mar, 2016 3 commits
  23. 19 Mar, 2016 1 commit
  24. 18 Mar, 2016 1 commit
  25. 17 Mar, 2016 1 commit
  26. 12 Mar, 2016 1 commit
  27. 10 Mar, 2016 2 commits
  28. 08 Mar, 2016 1 commit
  29. 04 Jan, 2016 1 commit
  30. 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.
  31. 18 Nov, 2015 2 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.