- 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
-
- 06 Dec, 2016 1 commit
-
-
Douwe Maan authored
Ensure state param has a valid value when filtering issuables. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/25064 This fix makes sure we only call safe methods on issuable when filtering by state. See merge request !2038
-
- 05 Dec, 2016 1 commit
-
-
Jacopo authored
counter This is done by: - Extending the IssuableFinder adding the non_archived option to the params - Overriding the #filter_params in the MergeRequestsAction - Passing the non_archived param in the nav/_group.html.haml navbar partial from the groups/merge_requests.html.haml
-
- 01 Dec, 2016 1 commit
-
-
Sean McGivern authored
Instead of doing n queries for n states, do one query to get all the counts grouped by state, and figure out what the count is for each state is from that. We can still cache the individual counts (it can't hurt), but this will help with initial load. Note that the `opened` scope on `Issuable` includes the `opened` and `reopened` states, which is why there's a special case.
-
- 29 Nov, 2016 2 commits
-
-
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 -
Douwe Maan authored
Fix missing access checks on issue lookup using IssuableFinder 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/controllers/projects/branches_controller.rb:39 - `before_action :authorize_push_code!` helpes limit/prevent exploitation. Always checks for reporter access so fine with confidential issues, issues only visible to team, etc. - [x] app/models/cycle_analytics/summary.rb:9 [`.count`] - [x] app/controllers/projects/todos_controller.rb:19 - [x] Potential double render in app/controllers/projects/todos_controller.rb - https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#cedccb227af9bfdf88802767cb58d43c2b977439_24_24 See merge request !2030
-
- 26 Nov, 2016 1 commit
-
-
Semyon Pupkov authored
-
- 16 Nov, 2016 1 commit
-
-
Robert Speicher authored
Prior, an administrator viewing a project's Labels page would see _all_ labels from every project they had access to, rather than only the labels of that specific project (if any). This was not an information disclosure, as admins have access to everything, but it was a performance issue.
-
- 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
-
- 01 Nov, 2016 2 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 28 Oct, 2016 1 commit
-
-
Adam Niedzielski authored
Do not pass project.owner because it may return a group and Labels::FindOrCreateService throws an error in this case. Fixes #23694.
-
- 25 Oct, 2016 5 commits
-
-
Stan Hu authored
Some users experienced 502 timeouts when viewing group labels. Labels#open_issues_count and Label#open_merge_requests_count were taking a long time to load because they were loading every ActiveRecord of the user-accessible projects into memory. This change modifies the system so that #presence and hence to_a isn't called. Closes #23684
-
Stan Hu authored
-
Stan Hu authored
-
Stan Hu authored
-
Stan Hu authored
If you attempt to move an issue from one project to another and leave labels blank, LabelsFinder would assign all labels in the new project to that issue. The issue is that :title is passed along to the Finder, but since it appears empty no filtering is done. As a result, all labels in the group are returned. This fix handles that case. Closes #23668
-
- 19 Oct, 2016 12 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
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 10 Oct, 2016 1 commit
-
-
Yorick Peterse authored
This commit introduces a Sidekiq worker that precalculates the list of trending projects on a daily basis. The resulting set is stored in a database table that is then queried by Project.trending. This setup means that Unicorn workers no longer _may_ have to calculate the list of trending projects. Furthermore it supports filtering without any complex caching mechanisms. The data in the "trending_projects" table is inserted in the same order as the project ranking. This means that getting the projects in the correct order is simply a matter of: SELECT projects.* FROM projects INNER JOIN trending_projects ON trending_projects.project_id = projects.id ORDER BY trending_projects.id ASC; Such a query will only take a few milliseconds at most (as measured on GitLab.com), opposed to a few seconds for the query used for calculating the project ranks. The migration in this commit does not require downtime and takes care of populating an initial list of trending projects.
-
- 05 Oct, 2016 1 commit
-
-
Yorick Peterse authored
== Public Projects This finder class now _only_ returns public projects. Previously this finder would also return private and internal projects. Including these projects makes caching data much harder and less efficient. Meanwhile including this data isn't very useful as very few users would be interested in seeing projects they have access to as trending. That is, the feature is more useful when you want to see what _other_ popular projects there are. == Caching The data returned by TrendingProjectsFinder is now cached for a day based on the number of months the data should be restricted to. The cache is not flushed explicitly, instead it's rebuilt whenever it expires. == Timings To measure the impact I changed the finder code to use the last 24 months instead of the last month. I then executed and measured 10 requests to the explore page. On the current "master" branch (commit 88fa5916) this would take an average of 2.43 seconds. Using the changes of this commit this was reduced to around 1.7 seconds. Fixes gitlab-org/gitlab-ce#22164
-
- 30 Sep, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 28 Sep, 2016 3 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>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 20 Sep, 2016 1 commit
-
-
barthc authored
-
- 07 Sep, 2016 1 commit
-
-
Z.J. van de Weg authored
-
- 31 Aug, 2016 1 commit
-
-
tiagonbotelho authored
-
- 30 Aug, 2016 1 commit
-
-
http://jneen.net/ authored
-
- 19 Aug, 2016 1 commit
-
-
Felipe Artur authored
-