Resolve "Destroying a project causes post_decline_request to be executed"
## What does this MR do?
Ensure we don't send "access request declined" to access requesters when a project is deleted.
## Are there points in the code the reviewer needs to double check?
I've created a service to decouple the notification sending from the AR model.
## Why was this MR needed?
Because there was an issue.
## What are the relevant issue numbers?
Fixes#18755, #18750.
## Does this MR meet the acceptance criteria?
- [x] No CHANGELOG needed.
- [x] Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !4744
Signed-off-by: Rémy Coutable <remy@rymai.me>
Implement custom notification level options
part of #12758
See merge request !4389
+ Move 'Edit Project/Group' out of membership-related partial
+ Show the access request buttons only to logged-in users
+ Put the request access buttons out of in a more visible button
+ Improve the copy in the #remove_member_message helper
Signed-off-by: Rémy Coutable <remy@rymai.me>
Here was the problem:
1. When determining whether a given blob is viewable text, gitlab_git reads the first 1024 bytes and checks with Linguist whether it is a text or binary file.
2. If the blob is text, GitLab will attempt to display it.
3. However, if the text has binary characters after the first 1024 bytes, then GitLab will attempt to load the entire contents, but the encoding will be ASCII-8BIT since there are binary characters.
4. The Error 500 results when GitLab attempts to display a mix UTF-8 and ASCII-8BIT.
To fix this, we load as much data as we are willing to display so that the detection will work properly. Requires
an update to gitlab_git: gitlab-org/gitlab_git!86
Closes#13826
Resolve "SHA parameter in accept merge request API"
Add a `sha` parameter to the MR merge API, which must match the source SHA for the branch to be merged.
Also add the same parameter to the UI:
@DouweM and I discussed adding some smart feature to that, like updating the source SHA on navigating to the diff tab, but for now it will just require a refresh 😃Closes#14139.
See merge request !4414
Set a `sha` parameter on the MR form. If this doesn't match the HEAD of
the source branch when the form is submitted, show a warning (like with
a merge conflict) and don't merge the branch.
Always read diff_view setting from the cookie
Prior, when the user had their view set to "parallel" and then visited a
merge request's changes tab _without_ passing the `view` parameter via
query string, the view would be parallel but the `Notes` class was
always instantiated with the default value from `diff_view` ("inline"),
resulting in broken markup when the form to add a line note was
dynamically inserted.
The cookie is set whenever the view is changed, so this value should
always be up-to-date.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/14557 and https://gitlab.com/gitlab-org/gitlab-ce/issues/15285
See merge request !3732
Douwe MaanandRémy Coutable
Douwe MaanandRobert Speicher
Douglas Barbosa Alexandre
Stan Hu
Jacob Schatz
Sean McGivern
Jacob Vosmaer (GitLab)
Kamil Trzcinski
Z.J. van de Weg
Dmitriy Zaporozhets
Grzegorz Bizon
Fatih Acet
Felipe Artur