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 this method responds with `text/html`. It is kind of unusable
if you open it in a browser. The browser thinks it is HTML and renders
it as HTML, meaning new lines are dropped. So it's very hard to
distinguish where the key starts and where it ends.
This commit changes the content type header to `text/plain`.
This spec featured the slowest tests in the entire suite. After some
debugging, the cause was found to be the large commit diff generated by
comparing the stable and master branches.
To fix this, the seed repository was modified to create a simple branch
off of master that consists of three simple commits and minor changes.
The spec was then updated to compare master to this branch instead of
stable. The result is a spec group that runs in under 30 seconds, down
from about 90.
Relative links within one system
When using relative links in md in repository file it will only link within the repository.
When using relative links in md in wiki page, it will only link to wiki pages.
Streamline the content of notification emails
In notification emails, the actual content of the email is often buried under several blocks of chrome — and may even be truncated or completely missing. Ideally, the notification emails would be like *real emails*: a short message of meaningful text, sent from the author of the change that triggered the notification.
This MR includes the following changes to notification emails:
* Remove much of the chrome (e.g. the "GitLab" header)
* Emphasize the content (no more small, grayed-out content)
* Add missing informations to the emails (issue description in "new issue" email, file name in "diff comment" email)
* Add a consistent "View in GitLab" link in the footer
* The assignee is displayed only if someone is assigned
* Fix a rendering bug when viewing emails with [Zimbra](http://www.zimbra.com/)
We use these patches at [Capitaine Train](http://www.capitainetrain.com), and it has been a surprisingly big productivity boost for us.
When an email notification concerns a specific object (issue, note,
merge request, etc.), add a link to the footer of the email that opens
the item's page in a web browser.
Rationale:
* The link is predictable: always the same text, always at the same
location, like any reliable tool.
* It allows to remove the inline-title in many emails, and leave only
the actual content of the message.
Dmitriy Zaporozhets
Pierre de La Morinerie
Robert Speicher
Ábner Silva de Oliveira
Dmitry Medvinsky
Federico Ravasio
Marin Jankovski
Greg Messner
Jeroen van Baarsen
Jacob Vosmaer
Jason Blanchard
