- 13 Dec, 2016 2 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Julian Zinn authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 11 Dec, 2016 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>
-
- 09 Dec, 2016 3 commits
-
-
Robert Schilling authored
-
Adam Niedzielski authored
The target branch of a merge request has to be a branch in the project for which the merge request is submitted. When a branch changes in a fork, it does not make sense to reload diffs of merge requests in the upstream project that use the same branch name as the target branch. Please note that it does make sense to reload diffs when the source branch changes.
-
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
-
- 08 Dec, 2016 1 commit
-
-
Dmitriy Zaporozhets authored
* add parent_id field to namespaces table to store relation with nested groups * create routes table to keep information about full path of every group and project * project/group lookup by full path from routes table Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 07 Dec, 2016 2 commits
-
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
- 06 Dec, 2016 12 commits
-
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
-
Kamil Trzcinski authored
Pass `updated_at` to get only incremental changes since last update
-
Yorick Peterse authored
This method already uses the cached method Repository#branch_count so there's no point in also caching has_visible_content?. Fixes gitlab-org/gitlab-ce#25278
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 05 Dec, 2016 3 commits
-
-
Ahmad Sherif authored
-
Bob Van Landuyt authored
When a merge request can only be merged when all discussions are resolved. This feature allows to easily delegate those discussions to a new issue, while marking them as resolved in the merge request. The user is presented with a new issue, prepared with mentions of all unresolved discussions, including the first unresolved note of the discussion, time and link to the note. When the issue is created, the discussions in the merge request will get a system note directing the user to the newly created issue.
-
Grzegorz Bizon authored
-
- 02 Dec, 2016 1 commit
-
-
Oswaldo Ferreira authored
-
- 01 Dec, 2016 4 commits
-
-
Yorick Peterse authored
By passing commit data to this worker we remove the need for querying the Git repository for every job. This in turn reduces the time spent processing each job. The migration included migrates jobs from the old format to the new format. For this to work properly it requires downtime as otherwise workers may start producing errors until they're using a newer version of the worker code.
-
Andrew Smith authored
-
Adam Niedzielski authored
when we care only about the number of commits We do not have to instantiate all objects in this case.
-
Adam Niedzielski authored
The implicit interface of project services states that the "execute" method is meant to be called when project hooks are executed. Currently JiraService does not support any project events even though JiraService#supported_events says that "commit" and "merge_request" are supported. They are only used to render correct options in JIRA configuration screen, but they are not supported. Because of that, this commit makes "execute" method a no-op.
-
- 29 Nov, 2016 4 commits
-
-
Grzegorz Bizon authored
-
Timothy Andrew authored
- Extract all common {push,merge} access level model code into the `ProtectedBranchAccess` module - Use the HTTP verb to define controller specs
-
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
-
- 28 Nov, 2016 4 commits
-
-
Sean McGivern authored
-
Adam Niedzielski authored
We only know the tag SHA after we create the tag. This means that we pass a different value to the hooks that happen before creating the tag, and a different value to the hooks that happen after creating the tag. This is not an ideal situation, but it is a trade-off we decided to make. For discussion of the alternatives please refer to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7700#note_18982873 "pre-receive" and "update" hooks always get the SHA of the commit that the tag points to. "post-receive" gets the tag SHA if it is an annotated tag or the commit SHA if it is an lightweight tag. Currently we always create annotated tags if UI is used.
-
Adam Niedzielski authored
This reverts commit ae51774b.
-
Adam Niedzielski authored
-
- 25 Nov, 2016 2 commits
-
-
hhoopes authored
* Added keyword arguments to truncated_diff_lines method to allow for using highlighting or not (html templates vs. text) * Tweaked templates for consistency and format appropriateness
-
hhoopes authored
Previously the `truncated_diff_lines` method for outputting a discussion diff took in already highlighted lines, which meant it wasn't reuseable for truncating ANY lines. In the way it was used, it also meant that for any email truncation, the whole diff was being highlighted before being truncated, meaning wasted time highlighting lines that wouldn't even be used (granted, they were being memoized, so perhaps this wasn't that great of an issue). I refactored truncation away from highlighting, in order to truncate formatted diffs for text templates in email, using `>`s to designate each line, but otherwise retaining the parsing already done to create `diff_lines`. Additionally, while notes on merge requests or commits had already been tested, there was no existing test for notes on a diff on an MR or commit. Added mailer tests for such, and a unit test for truncating diff lines.
-