| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Add issues/:iid/closed_by api endpoint
Closes #26437
See merge request !10511
|
| | | |
|
| | |
| |
| |
| | |
CE port of https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/962
|
| |/ |
|
| |
|
|
| |
Notice that this param is being supported since V3, but we have not added the proper docs for it
|
| | |
|
| |
|
|
| |
Closes #29631
|
| |
|
|
|
|
| |
API routes
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
| |
merge_request_for_resolving_discussions ->
merge_request_to_resolve_discussions_of
|
| |
|
|
|
| |
And deduplicate the finding of MR's & discussions. Now the searching
is done in the service, istead of the controller & the API.
|
| |
|
|
|
|
| |
Delegate a discussion in a merge request into a new issue.
The discussion wil be marked as resolved and a system note will be
added linking to the newly created issue.
|
| |
|
|
|
|
| |
- As opposed to the issue `id` that was previously being used.
- This brings the API routes closer to the web interface's routes.
- This is specific to API v4.
|
| |
|
|
| |
merge requests
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
New endpoints are:
POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/time_estimate"
POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/reset_time_estimate"
POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/add_spent_time"
POST :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/reset_spent_time"
GET :project_id/(issues|merge_requests)/(:issue_id|:merge_request_id)/time_stats"
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Use IssuesFinder for the /issues API resouce
- Tests for iid filter in project issues API resource
- Tests for No Milestone filter in issues API resources
The "No Milestone" case was not previously tested, and the `/issues`
resource did not support the the `milestone` parameter.
- Return issues where all labels match from the issues and project issues
API resources, like the group issues resource already does. See
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6825#note_17474533
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
|
|
|
| |
Current filtering for "/projects/:id/issues" endpoint
returns no results for "No Milestone" query.
This PR introduces fix by copying filtering from "/groups/:id/issues"
which works as expected.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Following a discussion in !7180
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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?
:warning: - Potentially untested
:bomb: - No test coverage
:traffic_light: - Test coverage of some sort exists (a test failed when error raised)
:vertical_traffic_light: - Test coverage of return value (a test failed when nil used)
:white_check_mark: - Permissions check tested
### Issue lookup with access check
Using `visible_to_user` likely makes these security issues too. See [Code smells](#code-smells).
- [x] :vertical_traffic_light: app/finders/notes_finder.rb:15 [`visible_to_user`]
- [x] :traffic_light: app/views/layouts/nav/_project.html.haml:73 [`visible_to_user`] [`.count`]
- [x] :white_check_mark: app/services/merge_requests/build_service.rb:84 [`issue.try(:confidential?)`]
- [x] :white_check_mark: lib/api/issues.rb:112 [`visible_to_user`]
- CHANGELOG: Prevented API returning issues set to 'Only team members' to everyone
- [x] :white_check_mark: lib/api/helpers.rb:126 [`can?(current_user, :read_issue, issue)`] Maybe here too?
- [x] :white_check_mark: 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
|
| |
|
|
|
|
|
|
| |
Fix label creation non members
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/23416
See merge request !2006
|
| |
|
|
| |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
after creating a new issue through the api
|
| | |
|
| |
|
|
| |
- Refactored SpamCheckService into SpamService
|
| |
|
|
|
|
|
| |
- Removed unnecessary column from `SpamLog`
- Moved creation of SpamLogs out of its own service and into SpamCheckService
- Simplified code in SpamCheckService.
- Moved move spam related code into Spammable concern
|
| |
|
|
|
|
|
| |
- Merged `AkismetSubmittable` into `Spammable`
- Clean up `SpamCheckService`
- Added tests for `Spammable`
- Added submit (ham or spam) options to `AkismetHelper`
|
| |
|
|
| |
legibility in `SpamCheckService`
|
| | |
|
| | |
|
| |
|
|
| |
for spam check.
|
| | |
|
| |
|
|
|
| |
rely only on IssuesFinder
docs and changelog
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Closes #15638
|
| |
|
|
|
|
|
|
| |
Previously all remote IPs appeared at 127.0.0.1, which made Akismet
not very useful. Using the ActionDispatch Remote IP (http://api.rubyonrails.org/classes/ActionDispatch/RemoteIp.html)
should provide more reliable results.
Closes #16629
|
| | |
|
