- 03 Apr, 2017 1 commit
-
-
Nick Thomas authored
-
- 23 Feb, 2017 2 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
- 24 Jan, 2017 1 commit
-
-
YarNayar authored
See !8028 and #24833
-
- 09 Dec, 2016 1 commit
-
-
Douwe Maan authored
Replace MR access checks with use of MergeRequestsFinder Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867
- Potentially untested - No test coverage - Test coverage of some sort exists (a test failed when error raised) - Test coverage of return value (a test failed when nil used) - Permissions check tested - [x] app/finders/notes_finder.rb:17 - [x] app/views/layouts/nav/_project.html.haml:80 [`.count`] - [x] app/controllers/concerns/creates_commit.rb:84 - [x] app/controllers/projects/commits_controller.rb:24 - [x] app/controllers/projects/compare_controller.rb:56 - [x] app/controllers/projects/discussions_controller.rb:29 - [x] app/controllers/projects/todos_controller.rb:27 - [x] app/models/commit.rb:268 - [x] lib/gitlab/search_results.rb:71 - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_267_266 Memoize ` merged_merge_request(current_user)` - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_248_247 Expected side effect for `merged_merge_request!`, consider `skip_authorization: true`. - [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_269_269 Scary use of unchecked `merged_merge_request?` See merge request !2033
-
- 29 Nov, 2016 1 commit
-
-
Douwe Maan authored
Replace issue access checks with use of IssuableFinder Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867 ## Which fixes are in this MR?
- Potentially untested - No test coverage - Test coverage of some sort exists (a test failed when error raised) - Test coverage of return value (a test failed when nil used) - Permissions check tested ### Issue lookup with access check Using `visible_to_user` likely makes these security issues too. See [Code smells](#code-smells). - [x] app/finders/notes_finder.rb:15 [`visible_to_user`] - [x] app/views/layouts/nav/_project.html.haml:73 [`visible_to_user`] [`.count`] - [x] app/services/merge_requests/build_service.rb:84 [`issue.try(:confidential?)`] - [x] lib/api/issues.rb:112 [`visible_to_user`] - CHANGELOG: Prevented API returning issues set to 'Only team members' to everyone - [x] lib/api/helpers.rb:126 [`can?(current_user, :read_issue, issue)`] Maybe here too? - [x] lib/gitlab/search_results.rb:53 [`visible_to_user`] ### Previous discussions - [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#b2ff264eddf9819d7693c14ae213d941494fe2b3_128_126 - [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#7b6375270d22f880bdcb085e47b519b426a5c6c7_87_87 See merge request !2031
-
- 06 Sep, 2016 1 commit
-
-
Valery Sizov authored
-
- 17 Mar, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 11 Mar, 2016 2 commits
-
-
Yorick Peterse authored
There's no need to order queries used as sub-queries and doing so can add potential overhead.
-
Yorick Peterse authored
Instead of plucking IDs this class now uses ActiveRecord::Relation objects. Plucking IDs is problematic as searching for projects can lead to a huge amount of IDs being loaded into memory only to be used as an argument for another query (instead of just using a sub-query).
-
- 24 Aug, 2015 1 commit
-
-
Valery Sizov authored
-
- 18 May, 2015 1 commit
-
-
Nikita Verkhovin authored
-
- 27 Aug, 2014 2 commits
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 26 Aug, 2014 2 commits
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
Dmitriy Zaporozhets authored
Gitlab::SearchResults and Gitlab::ProjectSearchResults are libraries we are going to use to get search results based on query, enitity type and pagination. It will allow us to get only issues from project #23 where title or description includes 'foo'. Ex: search_results = Gitlab::ProjectSearchResults.new(project.id, 'foo', 'issues') search_results.objects => # [<Issues #23>, <Issues #34>] search_results.issues_count => 2 search_results.total_count => 12 (it includes results from comments and merge requests too) Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-