Previously submitting a DELETE request to an issuable URL would be
enough to destroy it, but this should require human confirmation. We
now require that the `destroy_confirm` parameter is set to a truthy
value before this can complete.
In addition, we log a Sentry error if a deletion arrived without
confirmation.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/62387
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).
Adding, destroying and toggling emoji previously lacked services and
instead were performed through methods called on Awardable models.
This led to inconsistencies where relevant todos would be marked as done
only when emoji were awarded through our controllers, but not through
the API. Todos could also be marked as done when an emoji was being
removed.
Behaviour changes
- Awarding emoji through the API will now mark a relevant Todo as done
- Toggling an emoji off (destroying it) through our controllers will no
longer mark a relevant Todo as done
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63372
Previously we asked a user to enter a new slug before taking them to
the Create Page page.
As a UX improvement, we now take them to a randomly generated URI so
they can begin creating their new page.
https://gitlab.com/gitlab-org/gitlab-ce/issues/46299
Current `auth.log` uses `fullpath` and `ip`, while `api_json.log` uses
`remote_ip` and `path` for the same fields. Let's standardize these
namings to make it easier for people working with the data.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66167
Fixes deprecation warning:
```
DEPRECATION WARNING: The success? predicate is deprecated and
will be removed in Rails 6.0.
Please use successful? as provided by Rack::Response::Helpers.
```
GitLab has a mechanism that allows CI to clone repositories via HTTP
even when the HTTP protocol is disabled. This works as expected
when a project is private or internal. However, when a project is
public CI gets an error message that HTTP is not allowed. This
happens because Git only sends auth in a subsequent request after a
401 is returned first. For public projects, GitLab grabs onto that
unauthenticated request and sends it through since it recognizes
that Guests are ordinarily allowed to access the repository.
Later on this leads to a 403 since HTTP protocol is disabled.
Fix this by only continuing with unauthenticated requests when
HTTP is allowed.
It was originally returning 302 when the rate limit kicks in, because
using the the correct status code makes it easier to track rate limiting
events
Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/65974
- Use set_pipeline_variables to filter for visible pipelines
- Mimic response of nonexistent pipeline if not found
- Provide set_pipeline_variables as a before_filter for other actions
Querying all counts for the different search results in the same request
led to timeouts, so we now only calculate the count for the *current*
search results, and request the others in separate asynchronous calls.
Splits auto-refreshing of MR widget into 2 requests:
- the one which uses etag-caching and invalidates the fields on change
- the one without caching
The idea is to gradually move all the fields to etag-cached endpoint