An error occurred fetching the project authors.
  1. 20 Sep, 2017 1 commit
  2. 29 Aug, 2017 2 commits
  3. 07 Aug, 2017 1 commit
  4. 07 Jul, 2017 1 commit
  5. 06 Jul, 2017 1 commit
    • Yorick Peterse's avatar
      Added Cop to blacklist the use of `dependent:` · 8fbbf41e
      Yorick Peterse authored
      This is allowed for existing instances so we don't end up 76 offenses
      right away, but for new code one should _only_ use this if they _have_
      to remove non database data. Even then it's usually better to do this in
      a service class as this gives you more control over how to remove the
      data (e.g. in bulk).
      8fbbf41e
  6. 21 Jun, 2017 1 commit
  7. 16 Jun, 2017 3 commits
  8. 29 May, 2017 1 commit
  9. 04 May, 2017 1 commit
  10. 07 Apr, 2017 1 commit
  11. 02 Apr, 2017 1 commit
  12. 24 Mar, 2017 1 commit
  13. 15 Mar, 2017 1 commit
  14. 23 Feb, 2017 2 commits
  15. 06 Jan, 2017 1 commit
  16. 03 Jan, 2017 1 commit
  17. 20 Dec, 2016 1 commit
  18. 02 Dec, 2016 1 commit
  19. 23 Nov, 2016 1 commit
  20. 07 Oct, 2016 1 commit
    • Nick Thomas's avatar
      Add markdown cache columns to the database, but don't use them yet · e94cd6fd
      Nick Thomas authored
      This commit adds a number of _html columns and, with the exception of Note,
      starts updating them whenever the content of their partner fields changes.
      
      Note has a collision with the note_html attr_accessor; that will be fixed later
      
      A background worker for clearing these cache columns is also introduced - use
      `rake cache:clear` to set it off. You can clear the database or Redis caches
      separately by running `rake cache:clear:db` or `rake cache:clear:redis`,
      respectively.
      e94cd6fd
  21. 30 Sep, 2016 1 commit
  22. 27 Sep, 2016 1 commit
  23. 01 Jul, 2016 1 commit
  24. 29 Jun, 2016 1 commit
  25. 03 Jun, 2016 2 commits
  26. 19 May, 2016 1 commit
  27. 16 May, 2016 2 commits
    • Sean McGivern's avatar
      Return a relation with Postgres · e8058bd2
      Sean McGivern authored
      Postgres only needs to select a single column, so that can used as a
      sub-query where `Milestone.upcoming_ids_by_projects` is actually used in
      `IssuableFinder`.
      
      MySQL needs to select the `due_date` column because it's used in the
      `HAVING` clause, so it has to return an array of IDs.
      e8058bd2
    • 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
  28. 09 May, 2016 2 commits
  29. 06 May, 2016 1 commit
  30. 05 May, 2016 1 commit
  31. 21 Apr, 2016 3 commits