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.
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>
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.
Update API spec files to describe the correct class by changing `API::API` to the corresponding class, for example `API::AwardEmoji`.
Closes#24902
See merge request !7718
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
The amount of precision times have in databases is variable, so we need
tolerances when comparing in specs. It's better to have the tolerance defined
in one place than several.
MySQL could not have support for millisecond precision, depends on the MySQL version
so we just create issues in different seconds in a deterministic way
Valery Sizov
Zeger-Jan van de Weg
Rémy Coutable
Jacopo
mhasbini
Luke "Jared" Bennett
Oswaldo Ferreira
Douwe Maan
Alexander Randa
Adam Niedzielski
Toon Claes
Bob Van Landuyt
Bob Van Landuyt
Timothy Andrew
Sean McGivern
Jarka Kadlecova
Robert Schilling
Robert Speicher
Semyon Pupkov
Ruben Davila
Sean McGivern
David Eisner
Robert Speicher
Douwe Maan
Livier
Douglas Barbosa Alexandre
Nick Thomas
Paco Guzman