An error occurred fetching the project authors.
- 28 Aug, 2016 1 commit
-
-
barthc authored
prevent authored awardable thumbs votes prevent authored awardable thumbs votes
-
- 22 Aug, 2016 1 commit
-
-
Valery Sizov authored
-
- 19 Aug, 2016 1 commit
-
-
Felipe Artur authored
-
- 28 Jul, 2016 1 commit
-
-
Ahmad Sherif authored
-
- 14 Jul, 2016 1 commit
-
- 12 Jul, 2016 1 commit
-
-
Valery Sizov authored
-
- 01 Jul, 2016 1 commit
-
-
Grzegorz Bizon 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
-
- 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 2 commits
-
-
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
-
- 24 May, 2016 5 commits
-
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
- 12 May, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 10 May, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 09 May, 2016 1 commit
-
-
cnam-dep authored
-
- 06 May, 2016 2 commits
-
-
Takuya Noguchi authored
-
Zeger-Jan van de Weg authored
-
- 20 Apr, 2016 5 commits
-
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
Mehmet Beydogan authored
Fix typos on sorting dropdown related to due date Remove constant array and add Structs on Issue to keep due date data to fill options
-
Mehmet Beydogan authored
Add due_date text field to sidebar issue#show Add ability sorting issues by due date ASC and DESC Add ability to filtering issues by No Due Date, Any Due Date, Due to tomorrow, Due in this week options Add handling issue due_date field for MergeRequest Update CHANGELOG Fix ambigous match for issues#show sidebar Fix SCREAMING_SNAKE_CASE offenses for due date contants Add specs for due date sorting and filtering on issues
-
James Lopez authored
-
- 19 Apr, 2016 1 commit
-
-
James Lopez authored
-
- 02 Apr, 2016 1 commit
-
-
Rubén Dávila authored
This problem only was affecting the dev env.
-