25 Mar, 2014

2 commits

24 Mar, 2014

2 commits

  • 3d8ecbc9   Merge branch 'no-emails-for-mentions' into 'master' ... Browse Dir » 
     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.
    Dmitriy Zaporozhets
     
  • 65f5496e   Fix the merge notification email not being sent ... Browse Dir » 
    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
    Pierre de La Morinerie
     

22 Mar, 2014

1 commit

19 Mar, 2014

1 commit

14 Mar, 2014

1 commit

06 Mar, 2014

2 commits

05 Mar, 2014

1 commit

25 Feb, 2014

3 commits

  • 345b3d4b   Update tests and fix Finders readme ... Browse Dir » 
    Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
    Dmitriy Zaporozhets
     
  • c3a3f80a   Merge branch 'cleaner-email-headers' into 'master' ... Browse Dir » 
    Cleaner headers in Notification Emails

Make the informations available in the notification email headers (sender, recipient, subject, etc.) more readable and meaningful.

* Remove the email subject prefix
* Don't write the project namespace in email subjects
* Write the issue/merge request title in the notification email subject
* Make the email appear as sent from the action author (the actual email address is still `gitlab@gitlab.com`)

For instance, this is the notification email for a new issue comment before:

> From: gitlab@gitlab.com
> To: myemailaddress@gmail.com
> Subject: GitLab | GitLab HQ / GitLab-Shell | New note for issue #1234

And after :

> From: Nick Brown <gitlab@gitlab.com>
> To: myemailaddress@gmail.com
> Subject: GitLab-Shell |  Add local update hook  (#1234)

The recipient of the notification can easily get the gist of the message without even opening it — just by looking at how it appears in her inbox. None of the actual email addresses (From, To, Reply-to) changes, just the display name.

Having a consistent subject for all notification emails sent about some resource also allow good email clients to group the discussion by thread (although grouping in Mail.app still needs some work).
    Dmitriy Zaporozhets
     
  • 75eed4eb   Implement project collection service ... Browse Dir » 
    Main purpose is move big amount of methods from user, group, project
models and place filtering logic in one place.
It also fixes 500 error on group page for PostgreSQL

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
    Dmitriy Zaporozhets
     

24 Feb, 2014

1 commit

  • 5818cf06   Don't send an email for "mentioned in" notes ... Browse Dir » 
    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.
    Pierre de La Morinerie
     

19 Feb, 2014

1 commit

  • 96dded3e   Send emails from the author ... Browse Dir » 
    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.
    Pierre de La Morinerie
     

13 Feb, 2014

1 commit

  • 29cfd33d   Add email aliases for users ... Browse Dir » 
    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.
    Jason Hollingsworth
     

10 Feb, 2014

1 commit

22 Jan, 2014

1 commit

16 Jan, 2014

2 commits

15 Jan, 2014

5 commits

04 Dec, 2013

1 commit

14 Oct, 2013

1 commit

08 Oct, 2013

2 commits

17 Sep, 2013

1 commit

14 Sep, 2013

1 commit

13 Sep, 2013

2 commits

28 Aug, 2013

1 commit

25 Aug, 2013

1 commit

  • c8a115c0   Link issues from comments and automatically close them ... Browse Dir » 
    Any mention of Issues, MergeRequests, or Commits via GitLab-flavored markdown
references in descriptions, titles, or attached Notes creates a back-reference
Note that links to the original referencer. Furthermore, pushing commits with
commit messages that match a (configurable) regexp to a project's default
branch will close any issues mentioned by GFM in the matched closing phrase.
If accepting a merge request would close any Issues in this way, a banner is
appended to the merge request's main panel to indicate this.
    ash wilson
     

08 Aug, 2013

2 commits

30 Jul, 2013

1 commit

24 Jul, 2013

1 commit

17 Jul, 2013

1 commit