Fallback to group's owners/masters when a project has none for the "access requested email"
## What does this MR do?
From b31c5052f9:
Fallback to group's owners/masters when a project has none
A project in a group can have no explicit owners/masters,
in that case we fallbacks to the group's owners/masters.
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
Because of #18757.
## What are the relevant issue numbers?
Fixes#18757.
## Does this MR meet the acceptance criteria?
- [x] No need for CHANGELOG.
- [x] No need for documentation.
- [x] No API support added.
- [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 !4791
+ 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>
The repository push email can be very expensive to generate, especially
with syntax-highlighted diffs. Instead of generating the email for each
recipient, generate one email object and reset the Message-Id and To
headers for each recipient. (Cloning would also be expensive in the case
of large emails, although probably not as bad as generating from
scratch.)
A few things to note:
- The IncomingEmail feature is now enabled even without a
correctly-formatted sub-address
- Message-ID for new thread mail are kept the same so that subsequent
notifications to this thread are grouped in the thread by the email
service that receives the notification
(i.e. In-Reply-To of the answer == Message-ID of the first thread message)
- To maximize our chance to be able to retrieve the reply key, we look
for it in the In-Reply-To header and the References header
- The pattern for the fallback reply message id is "reply-[key]@[gitlab_host]"
- Improve docs thanks to Axil
1. Make the "subscribed" text in Issuable sidebar reflect the labels
subscription status
2. Current user mut be logged-in to toggle issue/MR/label subscription
Related to #2235.
This is done by:
1. Delaying the notification sending after the SSH key is commited in DB
2. Gracefully exit the mailer method if the record cannot be found
Adds a version requirement which it didn't have before, at 2.0.0. This
version has breaking API changes in that the namespace is now `FFaker`
instead of `Faker`.
Stan HuandRobert Speicher
Robert SpeicherandRobert Speicher
Rémy Coutable
DJ Mountney
Sean McGivern
Ben Bodenmiller
Jacob Vosmaer
David PadillaandRémy Coutable
Grzegorz Bizon
Jason LeeandRémy Coutable
Anton Baklanov
Zeger-Jan van de Weg
Kamil Trzcinski
Valery Sizov
Marin Jankovski
Dmitriy Zaporozhets
Vinnie Okada