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
1. Allow subscribing (the current user) to a label
- Refactor the `Subscription` coffeescript class
- The main change is that it accepts a container, and conducts all
DOM queries within its scope. We need this because the labels
page has multiple instances of `Subscription` on the same page.
2. Creating an issue or MR with labels notifies users subscribed to those labels
- Label `has_many` subscribers through subscriptions.
3. Adding a label to an issue or MR notifies users subscribed to those labels
- This only applies to subscribers of the label that has just been
added, not all labels for the issue.
Don't send an email for "mentioned in" notes
Currently, an email is sent every time a mentionable is referenced by an issue, a commit or a merge request: if I comment "This MR is related to #5", the watchers get one email for the comment, and another one stating "Issue #5 was mentioned by issue #13".
This is annoying — but the biggest issue is when pushing an existing branch. Every issue referenced by commit messages in this branch will get a new mention (which is fine), and dozens of emails will be sent for all these new mentions (which is not).
This commit fixes the spam by avoiding to send an email when a new mention is added to an existing mentionable. In most cases the email notification sent by the mentioner is enough.
The 'author_id_of_changes' attribute is not persisted in the database.
As we retrieve the merge request from the DB just before sending the
email, this attribute was always nil.
Also there was no tests for the merge notification code - tests have
been added.
Fix#6605
Currently, an email is sent every time a mentionable is referenced
by an issue, a commit or a merge request: if I comment "This MR is
related to #5", watchers get one email for the comment, and another
one stating "Issue #5 was mentioned by issue #13".
This is annoying — but the biggest issue is when pushing an existing
branch. Every issue referenced by commit messages in this branch will
get a new mention (which is fine), and dozens of emails will be sent
for all these new mentions (which is not).
This commit fixes the spam by avoiding to send an email when a new
mention is created. In most cases the email notification for the
mentioner is enough.
This changes the email "From" field from "gitlab@example.com" to either:
* "John Doe <gitlab@example.com>" if the author of the action is known,
* "GitLab <gitlab@example.com>" otherwise.
Rationale: this allow mails to appear as if they were sent by the
author. It appears in the mailbox more like a real discussion between
the sender and the receiver ("John sent: we should refactor this") and
less like a robot notifying about something.
Emails are used to associate commits with users. The emails
are not verified and don't have to be valid email addresses. They
are assigned on a first come, first serve basis.
Notifications are sent when an email is added.