Read about our upcoming Code of Conduct on this issue

This instance was upgraded to Heptapod 0.28.0 today

  1. 06 Dec, 2016 1 commit
  2. 19 Nov, 2016 1 commit
  3. 17 Nov, 2016 1 commit
  4. 09 Nov, 2016 1 commit
  5. 07 Nov, 2016 1 commit
    • Yorick Peterse's avatar
      Added IssueCollection · 026d0efb30e7
      Yorick Peterse authored
      This class can be used to reduce a list of issues down to a subset based
      on user permissions. This class operates in such a way that it can
      reduce issues using as few queries as possible, if any at all.
  6. 28 Oct, 2016 1 commit
  7. 19 Oct, 2016 8 commits
  8. 07 Oct, 2016 1 commit
    • Nick Thomas's avatar
      Add markdown cache columns to the database, but don't use them yet · af001f6c6325
      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`,
  9. 20 Sep, 2016 1 commit
  10. 19 Sep, 2016 2 commits
  11. 14 Sep, 2016 1 commit
  12. 28 Aug, 2016 1 commit
  13. 22 Aug, 2016 1 commit
  14. 19 Aug, 2016 1 commit
  15. 28 Jul, 2016 1 commit
  16. 14 Jul, 2016 1 commit
  17. 12 Jul, 2016 1 commit
  18. 01 Jul, 2016 1 commit
  19. 23 Jun, 2016 2 commits
    • Paco Guzman's avatar
    • Sean McGivern's avatar
      Fix pagination on sorts with lots of ties · 8f667bd25b23
      Sean McGivern authored
      Postgres and MySQL don't guarantee that pagination with `LIMIT` and
      `OFFSET` will work if the ordering isn't unique. From the Postgres docs:
      > When using `LIMIT`, it is important to use an `ORDER BY` clause that
      > constrains the result rows into a unique order. Otherwise you will get
      > an unpredictable subset of the query's rows
          [1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten
          [2] pry(main)> issues.count
          => 81
          [3] pry(main)> issues.uniq.count
          => 42
          [1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten
          [2] pry(main)> issues.count
          => 81
          [3] pry(main)> issues.uniq.count
          => 81
  20. 08 Jun, 2016 2 commits
    • Alejandro Rodríguez's avatar
      Fix pseudo n+1 queries with Note and Note Authors in issuables APIs · f2b94053dcdf
      Alejandro Rodríguez authored
      This was not a clear cut n+1 query, given that if you're directly subscribed to all issues
      that the API is returning you never really need to check for the notes. However, if you're
      subscribed to _all_ of them, then for each issuable you need to go once to `notes`, and
      once to `users` (for the authors). By preemtively loading notes and authors, at worst you have
      1 extra query, and at best you saved 2n extra queries. We also took advantage of this preloading
      of notes when counting user notes.
    • Alejandro Rodríguez's avatar
      Remove `projects` inclusion in `notes_with_associations` to skip some unnecessary queries · 8afcc028b35e
      Alejandro Rodríguez authored
      `notes_with_associations` are used for `participant` declarations, but `Participable`
      only really cares about the target entity project, and not the participants
      `notes_with_associations` are also used in `Commit::has_been_reverted?` which
      employs the reference extractor of the commit, so no references to the notes
      projects are made there (`Mentionable::all_references` cares only about the
      `author` and other `attr_mentionable`). A paralel situation occurs on
  21. 06 Jun, 2016 2 commits
  22. 03 Jun, 2016 2 commits
  23. 02 Jun, 2016 4 commits
  24. 01 Jun, 2016 2 commits
    • Yorick Peterse's avatar
      Refactor Participable · 8f2d80473517
      Yorick Peterse authored
      There are several changes to this module:
      1. The use of an explicit stack in Participable#participants
      2. Proc behaviour has been changed
      3. Batch permissions checking
      == Explicit Stack
      Participable#participants no longer uses recursion to process "self" and
      all child objects, instead it uses an Array and processes objects in
      breadth-first order. This allows us to for example create a single
      Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
      a ReferenceExtractor removes the need for running potentially many SQL
      queries every time a Proc is called on a new object.
      == Proc Behaviour Changed
      Previously a Proc in Participable was expected to return an Array of
      User instances. This has been changed and instead it's now expected that
      a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
      value of the Proc is ignored.
      == Permissions Checking
      The method Participable#participants uses
      Ability.users_that_can_read_project to check if the returned users have
      access to the project of "self" _without_ running multiple SQL queries
      for every user.
    • Z.J. van de Weg's avatar
      Incorportate feedback · 8ec147aac29a
      Z.J. van de Weg authored