It adds a hash response which includes
the count, success state and the moved
issues itself so the caller has additional
information about the result of the
process.
Add specs for new endpoint to move multiple issues.
Add changelog entry
Just check the first issue for the ability to move / update
Add specs for exceeding limits and malformed requests
Changed name of shared examples
Change title of changelog entry
Use %i instead of %w
Check permission to update issue on project instead of board
Use admin_issue permission to check for issue move ability
Changed variable name to avoid shadow issue_params method
Rename route to bulk_move
Change route definition
Check permissions for each issue
Combine methods for parameters permit check
Remove extra context
Change description of context
Check param for type Array
Add unit tests to MoveService
Use before_action for permission check
Use set instead of let!
Use let's instead of set
This ensures that we have more visibility in the number of SQL queries
that are executed in web requests. The current threshold is hardcoded to
100 as we will rarely (maybe once or twice) change it.
In production and development we use Sentry if enabled, in the test
environment we raise an error. This feature is also only enabled in
production/staging when running on GitLab.com as it's not very useful to
other users.
In GitLab EE, a GitLab instance can be read-only (e.g. when it's a Geo
secondary node). But in GitLab CE it also might be useful to have the
"read-only" idea around. So port it back to GitLab CE.
Also having the principle of read-only in GitLab CE would hopefully
lead to less errors introduced, doing write operations when there
aren't allowed for read-only calls.
Closesgitlab-org/gitlab-ce#37534.
