It consists of two parts:
1. Redirecting users to the configured external storage
1. Allowing the external storage to request the static object(s)
on behalf of the user by means of specific tokens
Part of https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6829
Sorting preference functionality has been extracted
from `IssuableCollections` to a new `SortingPreference`
concern in order to reuse this functionality in projects
(and groups in the future).
Remove project from NotesFinder constructor
Add project parameter to specs
Also look for methods in private scope
Fix specs to match new NotesFinder constructor
Add spec for concern IssuableActions
Add shared samples for discussions endpoint
Add schema validations for discussions
Fix rubocop style issue
Make target assignable
Use new possibility to provide target
We use a leading dash for certain things like the WebIDE, which
had the side effect of losing the `params[:continue][:to]` param when
opening the WebIDE on a project where the user doesn't have push access
and therefore needs to fork the project first.
The check for continue_params&.key?(:to) in Projects::ImportsController
caused an exception in redirect_to if this key contained a nil value.
Since url_for won't add any params for an empty hash, we can just return
that in continue_params if params[:continue] isn't present, and simplify
the code in the controllers to check for the values we actually want to
use.
Previously import_url would always be present in the update parameters,
which would cause the validation to fail. We now only include this
parameter only if there is URL given.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/62708
String#underscore isn't particularly slow, but it's possible for us to
call it many times in a users autocomplete request, with mostly-static
values ('User', 'Group', etc.). We can memoise this and save a
surprising amount of time (around 10% of the total request time in some
cases).
Users downloading non-ASCII attachments would see garbled characters.
When used with object storage, AWS S3 would return an InvalidArgument
error: Header value cannot be represented using ISO-8859-1.
Per RFC 5987 and RFC 6266, Content-Disposition should be encoded
properly. This commit takes the Rails 6 implementation of
ActiveSuppport::Http::ContentDisposition
(https://github.com/rails/rails/pull/33829) and ports it here.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/47673
In order to let users' sorting preferences transfer between devices, we
save the preference for issues and MRs (one preference for issues, one
for MRs) in the backend inside the UserPreference object
Updates specs to use new rails5 format.
The old format:
`get :show, { some: params }, { some: headers }`
The new format:
`get :show, params: { some: params }, headers: { some: headers }`
There were several issues:
1. With Google Cloud Storage, we can't override the Content-Type with
Response-Content-Type once it is set. Setting the value to
`application/octet-stream` doesn't buy us anything. GCS defaults to
`application/octet-stream`, and AWS uses `binary/octet-stream`. Just remove
this `Content-Type` when we upload new files.
2. CarrierWave and fog-google need to support query parameters:
https://github.com/fog/fog-google/pull/409/files, https://github.com/carrierwaveuploader/carrierwave/pull/2332/files.
CarrierWave has been monkey-patched until an official release.
3. Workhorse also needs to remove the Content-Type header in the request
(ef80978ff8/internal/objectstore/object.go (L66)),
or we'll get a 403 error when uploading due to signed URLs not matching the headers.
Upgrading to Workhorse 6.1.0 for https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/297
will make Workhorse use the headers that are used by Rails.
Closes#49957
We need to preload the ancestors of search results after applying
pagination limits. This way the search results itself are paginated,
but not the ancestors.
If we don't do this, we might not preload a parent group of a search
result as it has been cut off by pagination.