- 20 Jul, 2016 1 commit
-
-
Douwe Maan authored
-
- 18 Jul, 2016 1 commit
-
-
Kamil Trzcinski authored
-
- 15 Jul, 2016 2 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 14 Jul, 2016 2 commits
-
-
dixpac authored
* There where path where +1 was stored as +1 not as thumbsup that was causing problems such as showing thumbsup icon 2 time. I fixed this to always normalize and store +1 as tumbsup
-
- 12 Jul, 2016 1 commit
-
-
Valery Sizov authored
-
- 06 Jul, 2016 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
Extract parts of LegacyDiffNote into DiffOnNote concern and move part of responsibility to other classes
-
- 01 Jul, 2016 2 commits
-
-
Grzegorz Bizon authored
-
James Lopez authored
-
- 30 Jun, 2016 1 commit
-
-
Sean McGivern authored
-
- 29 Jun, 2016 3 commits
-
-
James Lopez authored
-
James Lopez authored
-
James Lopez authored
-
- 23 Jun, 2016 2 commits
-
-
Paco Guzman authored
-
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 Before: [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 After: [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
-
- 21 Jun, 2016 1 commit
-
-
Paco Guzman authored
-
- 18 Jun, 2016 1 commit
-
-
Stan Hu authored
When using #XYZ in Markdown text, if XYZ exceeds the maximum value of a signed 32-bit integer, we get an exception when the Markdown render attempts to run `where(iids: XYZ)`. Introduce a method that will throw out out-of-bounds values. Closes #18777
-
- 16 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 13e37a3e.
-
James Lopez authored
-
- 15 Jun, 2016 1 commit
-
-
Paco Guzman authored
Avoiding N+1 when showing grouped awards and when calculating participants for awardable entities
-
- 14 Jun, 2016 2 commits
-
-
Rémy Coutable authored
+ Move 'Edit Project/Group' out of membership-related partial + Show the access request buttons only to logged-in users + Put the request access buttons out of in a more visible button + Improve the copy in the #remove_member_message helper Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 08 Jun, 2016 2 commits
-
-
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 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`.
-
- 06 Jun, 2016 2 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Thijs Wouters authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 02 Jun, 2016 4 commits
-
-
Paco Guzman authored
This will be useful when you want to ask for the number of items and later iterate over them, without needing to ask if the association is load or not. So you avoid extra database queries
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Josh Frye authored
-
Josh Frye authored
-
- 01 Jun, 2016 3 commits
-
-
James Lopez authored
-
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 authored
-
- 31 May, 2016 2 commits
-
-
Felipe Artur authored
-
Felipe Artur authored
-