- 19 Nov, 2016 1 commit
-
-
Ruben Davila authored
-
- 17 Nov, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 09 Nov, 2016 1 commit
-
-
Douwe Maan authored
Honour issue and merge request visibility in their respective finders This MR fixes a security issue with the IssuesFinder and MergeRequestFinder where they would return items the user did not have permission to see. This was most visible on the issue and merge requests page for a group containing projects that had set their issues or merge requests to "private". Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/22481 See merge request !2000
-
- 07 Nov, 2016 1 commit
-
-
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.
-
- 28 Oct, 2016 1 commit
-
-
Guilherme Salazar authored
fix issues pointed out in !6527 add task completion status feature to CHANGELOG
-
- 19 Oct, 2016 8 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 07 Oct, 2016 1 commit
-
-
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.
-
- 20 Sep, 2016 1 commit
-
-
Timothy Andrew authored
- Move things common to `Issue` and `MergeRequest` into `Issuable` - Move more database-specific functions into `Gitlab::Database` - Indentation changes and other minor refactorings.
-
- 19 Sep, 2016 2 commits
-
-
Z.J. van de Weg authored
-
Timothy Andrew authored
-
- 14 Sep, 2016 1 commit
-
-
Timothy Andrew authored
-
- 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 1 commit
-
-
Felipe Artur authored
-