Skip to content

Improvements in email notifications on issues and pull requests #5083

Closed

Description

@rasmk

I would like to see some improvements in email notifications Gitea sends on issues and pull requests.

Content extensions:

  • distinguish issues and PRs in email subject and body
  • distinguish whether the issue is new, updated or closed in email subject and body
  • have different notifications on different comment types (e.g. different email, when I get assigned to an issue)

For that, I was thinking about having templates for subjects and adding some more data (e.g. issue and comment) to the data of the body template, so that custom templates can make use of that. Having separate templates per comment type may be an option too.

Besides, I would like to receive some more emails than today:

  • when user assignment changes, especially, when I get assigned to the issue/PR
  • on coder review, possibly both line-review comments and global review comment

Nice to have: defer the email sending and bundle some related updates into a single mail. This should be particularly useful for the review notifications. This may be somehow related to #145 by @andreynering.

I would like to hear some feedback. Perhaps I could contribute a PR.

Activity

  1. added
    type/enhancementAn improvement of existing functionality
    type/proposalThe new feature has not been accepted yet but needs to be discussed first.
    on Oct 15, 2018
  2. kolaente commented on Oct 18, 2018

    @kolaente
    Member

    I looked into this and after about an hour I gave up. The whole thing is not built very good. We have notifications, these are ok and get updated far more often than emails are sent. One would expect we have some kind of goroutine which sends mails based on notifications, but the whole notification implementation doesn't send any mails. Mails are being send directly by the function which creates an issue/pr comment. But not for all kinds of comments.... (this is the reason for #4279)

    IMHO we should refactor these things in three steps:

    1. Refactor the way emails are sent so they're sent based on notifications instead of issue comments
    2. Built email content messages based on the notification type, then later add translatable strings (work for this has been done in Added user language setting #3875)
    3. Make sure notifications are built for every issue action (assigned, unassigned, updated, etc.). Later possibility to make this configurable on a per-user basis, letting the user decide which kind of notifications he wants to recieve.
  3. lunny commented on Oct 18, 2018

    @lunny
    Member

    @kolaente see #5085 , I will send another PR about mail notification after that merged.

  4. kolaente commented on Oct 18, 2018

    @kolaente
    Member

    @lunny Great, I haven't seen that!

  5. rasmk commented on Oct 20, 2018

    @rasmk
    Author

    @kolaente, if email is generated on every action, option to configure, which emails the user is interested in is, in my opinion, a must. Currently there are too few emails sent. But I would not exchange it for too many.
    I would say, this should be configurable not only per user, but on per user/repo combination basis. There are some repos I like to know about virtually everything, some I want to be informed about some major events (e.g. PR approval or merge) and some, I do not want to get anything, even though I am a member there. Best if there were global settings for the user, that could be overwritten per repo.
    There is currently no UI for maintaining user settings per repo, so I perhaps request for too much. If not doable, email rules for help. But then it would be quite important to have key informations in email subject. Good case for subject templates I proposed in OP.

    Another way to reduce email overload is deferring email sending and bundling some actions together. E.g. if I set a milestone, labels and assignee on an issue, they are separate actions as I can tell from the UI. But logically, I would not like to receive several mails for them. Or another case, line comments and review comment. If somebody is working on PR review, it does not make much sense to push every action as an email. Instead, they could be combined together in a single message. I worked for a while with BitBucket. It was behaving that way (I mean PR review), as far as I remember.

    I am too new to Gitea to contribute any code on that level of rework. Looking forward for the PR promised by @lunny.

  6. lunny commented on Oct 21, 2018

    @lunny
    Member

    @rasmk I agree with you we need a notification configuration UI after the mail refactoring finished.

  7. saitho commented on May 10, 2019

    @saitho
    Contributor

    The notification refactoring mentioned was #5085, right? Can we tackle this issue now? :)

  8. lunny commented on May 11, 2019

    @lunny
    Member
  9. oscarlofwenhamn commented on May 22, 2019

    @oscarlofwenhamn
    Contributor

    I agree with @rasmk that we would need configuration options with an increase of emails. Is configuration available at all at the moment? I was contacted by a user with the request of opting-out of certain notification emails, though I haven't come across this functionality so far in Gitea. The ability to customize notifications for different repos would be brilliant, as certain repos may require greater attention than others.

  10. markusamshove commented on Sep 16, 2019

    @markusamshove
    Contributor

    I would like to see a way to disable comments from specific users resulting in a mail/notification.

    We have technical users (bots) that write comments into every PR and when I create a PR, I already get multiple mails :-)

  11. guillep2k commented on Oct 15, 2019

    @guillep2k
    Member

    #8329 partially addresses this.
    Related to #145

  12. lunny commented on Sep 3, 2020

    @lunny
    Member

    Since the email templates could be overrided, I think we can close this one.

  13. mrsdizzie commented on Sep 7, 2020

    @mrsdizzie
    Member

    Agree most of this is resolved/possible now

  14. locked and limited conversation to collaborators on Nov 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type/enhancementAn improvement of existing functionalitytype/proposalThe new feature has not been accepted yet but needs to be discussed first.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions