An error occurred fetching the project authors.
  1. 08 Jun, 2016 1 commit
    • Alejandro Rodríguez's avatar
      Remove `projects` inclusion in `notes_with_associations` to skip some unnecessary queries · ad83c308
      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
      projects.
      
      `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
      `Issue::referenced_merge_requests`.
      ad83c308
  2. 02 Jun, 2016 1 commit
  3. 01 Jun, 2016 1 commit
    • Yorick Peterse's avatar
      Refactor Participable · 580d2501
      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.
      580d2501
  4. 19 Apr, 2016 2 commits
  5. 18 Apr, 2016 1 commit
  6. 13 Apr, 2016 1 commit
  7. 11 Apr, 2016 2 commits
  8. 01 Apr, 2016 1 commit
  9. 22 Mar, 2016 1 commit
  10. 03 Mar, 2016 1 commit
  11. 22 Feb, 2016 1 commit
  12. 19 Feb, 2016 12 commits
  13. 30 Jan, 2016 1 commit
  14. 09 Dec, 2015 1 commit
  15. 07 Dec, 2015 2 commits
  16. 04 Dec, 2015 1 commit
  17. 01 Dec, 2015 2 commits
  18. 30 Nov, 2015 1 commit
  19. 22 Oct, 2015 1 commit
  20. 20 Oct, 2015 1 commit
  21. 14 Oct, 2015 1 commit
  22. 12 Oct, 2015 1 commit
  23. 23 Jun, 2015 1 commit
  24. 10 Jun, 2015 1 commit
  25. 26 May, 2015 1 commit