- 06 Apr, 2017 1 commit
-
-
Jacopo authored
Extended ProjectFinder in order to handle the following options: - current_user - which user use - project_ids_relation: int[] - project ids to use - params: - trending: boolean - non_public: boolean - starred: boolean - sort: string - visibility_level: int - tags: string[] - personal: boolean - search: string - non_archived: boolean GroupProjectsFinder now inherits from ProjectsFinder. Changed the code in order to use the new available options.
-
- 15 Mar, 2017 1 commit
-
-
Sean McGivern authored
-
- 06 Mar, 2017 1 commit
-
-
Jarka Kadlecova authored
-
- 23 Feb, 2017 1 commit
-
-
Douwe Maan authored
-
- 17 Feb, 2017 1 commit
-
-
mhasbini authored
-
- 11 Jan, 2017 1 commit
-
-
Clement Ho authored
-
- 09 Jan, 2017 4 commits
-
-
Lin Jen-Shin authored
We should separate the idea of not finding anyone, and the idea of against no one.
-
Lin Jen-Shin authored
So that we don't have to check it again in somewhere else, and we don't really need to know if it's presented as NONE Feedback: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7345/diffs#note_20123999
-
Clement Ho authored
-
- 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
-
- 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 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 19 Oct, 2016 4 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
- 30 Sep, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 20 Sep, 2016 1 commit
-
-
barthc authored
-
- 30 Aug, 2016 1 commit
-
-
http://jneen.net/ authored
-
- 01 Aug, 2016 1 commit
-
-
zs authored
Provide more sensible default sort order for issues and merge requests based on the following table: | type | state | default sort order | |----------------|--------|--------------------| | issues | open | last created | | issues | closed | last updated | | issues | all | last created | | merge requests | open | last created | | merge requests | merged | last updated | | merge requests | closed | last updated | | merge requests | all | last created |
-
- 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
-
- 31 May, 2016 1 commit
-
-
Felipe Artur authored
-
- 24 May, 2016 2 commits
-
-
Felipe Artur authored
-
Felipe Artur authored
-
- 16 May, 2016 1 commit
-
-
Sean McGivern authored
Before: we took the next milestone due across all projects in the search and found issues whose milestone title matched that one. Problems: 1. The milestone could be closed. 2. Different projects have milestones with different schedules. 3. Different projects have milestones with different titles. 4. Different projects can have milestones with different schedules, but the _same_ title. That means we could show issues from a past milestone, or one that's far in the future. After: gather the ID of the next milestone on each project we're looking at, and find issues with those milestone IDs. Problems: 1. For a lot of projects, this can return a lot of IDs. 2. The SQL query has to be different between Postgres and MySQL, because MySQL is much more lenient with HAVING: as well as the columns appearing in GROUP BY or in aggregate clauses, MySQL allows them to appear in the SELECT list (un-aggregated).
-
- 21 Apr, 2016 1 commit
-
-
Rémy Coutable authored
This is not needed anymore after !3815. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 20 Apr, 2016 4 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>
-
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
-