Send Email to Assignee on Assignment #3982

New Issue

GiteaMirror · 2025-11-02T05:32:43-06:00

GiteaMirror commented

2025-11-02 05:32:43 -06:00

Originally created by @jag3773 on GitHub (Sep 18, 2019).

Description

This is a feature request to send an email to an assignee when that person is assigned an issue (unless they assigned themselves).

This is referenced in and similar to https://github.com/go-gitea/gitea/issues/5083 but I think it deserves it's own issue as it could be implemented independent of that more complex issue.

Based on our user's feedback the expected behavior is that assigning an issue to someone will email them. Otherwise, you have to assign someone and then do something like write a comment to let them know you've assigned it to them (that's redundant and painful).

Seems like this would be straightforward to add into https://github.com/go-gitea/gitea/blob/master/modules/notification/mail/mail.go and would make the email notifications more intuitive.

Originally created by @jag3773 on GitHub (Sep 18, 2019). ## Description This is a feature request to send an email to an assignee when that person is assigned an issue (unless they assigned themselves). This is referenced in and similar to https://github.com/go-gitea/gitea/issues/5083 but I think it deserves it's own issue as it could be implemented independent of that more complex issue. Based on our user's feedback the expected behavior is that assigning an issue to someone will email them. Otherwise, you have to assign someone and then do something like write a comment to let them know you've assigned it to them (that's redundant and painful). Seems like this would be straightforward to add into https://github.com/go-gitea/gitea/blob/master/modules/notification/mail/mail.go and would make the email notifications more intuitive.

GiteaMirror added the type/enhancement label 2025-11-02 05:32:43 -06:00

GiteaMirror closed this issue

2025-11-02 05:32:43 -06:00

GiteaMirror commented

2025-11-02 05:32:44 -06:00

@HenrikBengtsson commented on GitHub (Sep 19, 2019):

Sounds like a useful feature but I also think there should be an option (site, owner, or repos wide) to enable/disable this - e.g. to avoid flooding people with notification emails.

@HenrikBengtsson commented on GitHub (Sep 19, 2019): Sounds like a useful feature but I also think there should be an option (site, owner, or repos wide) to enable/disable this - e.g. to avoid flooding people with notification emails.

GiteaMirror commented

2025-11-02 05:32:44 -06:00

@davidsvantesson commented on GitHub (Sep 19, 2019):

@HenrikBengtsson Better with a user setting to allow user to choose what notifications to receive as e-mails?
I don't think e-mail at assignment will be the worst notification flooding.

@davidsvantesson commented on GitHub (Sep 19, 2019): @HenrikBengtsson Better with a user setting to allow user to choose what notifications to receive as e-mails? I don't think e-mail at assignment will be the worst notification flooding.

GiteaMirror commented

2025-11-02 05:32:44 -06:00

@bhalbright commented on GitHub (Oct 17, 2019):

@davidsvantesson I had been working on the same issue before noticing your PR :) My mistake to not post that I was looking at it. But I wanted to comment something as food for thought, one outstanding question I had about the existing code was the scenario where an issue is created with an assignee (as opposed to adding the assignee later). In this scenario, currently the assignee gets an email with the initial comment on the issue (because they are considered a participant). However, nothing in the email lets the user know they were assigned. I was going to propose that in this scenario the email include a sentence indicating they were also assigned to it. But I'll leave it for you to decide whether to address it or not. The alternatives IMO would be to either send a separate email about the assignment (like the add assignee does in your PR), or do nothing and it just continues to work as it is today. Maybe the way it works now is fine with most people, I don't know.

@bhalbright commented on GitHub (Oct 17, 2019): @davidsvantesson I had been working on the same issue before noticing your PR :) My mistake to not post that I was looking at it. But I wanted to comment something as food for thought, one outstanding question I had about the existing code was the scenario where an issue is created with an assignee (as opposed to adding the assignee later). In this scenario, currently the assignee gets an email with the initial comment on the issue (because they are considered a participant). However, nothing in the email lets the user know they were assigned. I was going to propose that in this scenario the email include a sentence indicating they were also assigned to it. But I'll leave it for you to decide whether to address it or not. The alternatives IMO would be to either send a separate email about the assignment (like the add assignee does in your PR), or do nothing and it just continues to work as it is today. Maybe the way it works now is fine with most people, I don't know.

GiteaMirror commented

2025-11-02 05:32:45 -06:00

@jag3773 commented on GitHub (Oct 17, 2019):

My preference would be to catch the initial email and add a sentence noting that it has been assigned to that person (rather than two nearly identical emails at nearly the same time!).

@jag3773 commented on GitHub (Oct 17, 2019): My preference would be to catch the initial email and add a sentence noting that it has been assigned to that person (rather than two nearly identical emails at nearly the same time!).

GiteaMirror commented

2025-11-02 05:32:45 -06:00

@guillep2k commented on GitHub (Oct 17, 2019):

@bhalbright @davidsvantesson @jag3773 I'm working on a template system for e-mails (#8329). This should be covered by that.

@guillep2k commented on GitHub (Oct 17, 2019): @bhalbright @davidsvantesson @jag3773 I'm working on a template system for e-mails (#8329). This should be covered by that.

GiteaMirror commented

2025-11-02 05:32:45 -06:00

@davidsvantesson commented on GitHub (Oct 17, 2019):

@guillep2k So maybe finalizing this issue should wait until that is merged. It will conflict anyhow.

@davidsvantesson commented on GitHub (Oct 17, 2019): @guillep2k So maybe finalizing this issue should wait until that is merged. It will conflict anyhow.

GiteaMirror commented

2025-11-02 05:32:46 -06:00

@guillep2k commented on GitHub (Oct 17, 2019):

@davidsvantesson My PR will take at least another week (I'm very busy ATM). Don't worry about it, go ahead and I'll merge your changes in my PR when they're merged.

@guillep2k commented on GitHub (Oct 17, 2019): @davidsvantesson My PR will take at least another week (I'm very busy ATM). Don't worry about it, go ahead and I'll merge your changes in my PR when they're merged.

GiteaMirror commented

2025-11-02 05:32:46 -06:00

@davidsvantesson commented on GitHub (Oct 17, 2019):

@bhalbright I am aware about the create issue case but was not sure how to handle it. Do you think the mail should

always state who / which people was assigned, or
only state "you were assigned" to the person that was assigned

With guillep2k's PR maybe also the subject could state "created and assigned to you"?

@davidsvantesson commented on GitHub (Oct 17, 2019): @bhalbright I am aware about the create issue case but was not sure how to handle it. Do you think the mail should - always state who / which people was assigned, or - only state "you were assigned" to the person that was assigned With guillep2k's PR maybe also the subject could state "created and assigned to you"?

GiteaMirror commented

2025-11-02 05:32:46 -06:00

@guillep2k commented on GitHub (Oct 17, 2019):

@bhalbright I am aware about the create issue case but was not sure how to handle it. Do you think the mail should
* always state who / which people was assigned, or

* only state "you were assigned" to the person that was assigned

To keep this PR on-topic, I'd send a separate notification "xxx asigned you for yyy", even if the user will get another notification about the issue creation itself. Just my thoughts.

With guillep2k's PR maybe also the subject could state "created and assigned to you"?

With the current state of the PR, {{if cond}} and other control structures are supported. It's only a matter of making the required metadata available to the template engine.

@guillep2k commented on GitHub (Oct 17, 2019): > > > @bhalbright I am aware about the create issue case but was not sure how to handle it. Do you think the mail should > > * always state who / which people was assigned, or > > * only state "you were assigned" to the person that was assigned > To keep this PR on-topic, I'd send a separate notification "_xxx_ asigned you for _yyy_", even if the user will get another notification about the issue creation itself. Just my thoughts. > > With guillep2k's PR maybe also the subject could state "created and assigned to you"? With the current state of the PR, `{{if cond}}` and other control structures are supported. It's only a matter of making the required metadata available to the template engine.

GiteaMirror commented

2025-11-02 05:32:46 -06:00

@davidsvantesson commented on GitHub (Oct 17, 2019):

@guillep2k I tested on GitHub and they do it like you suggest (two e-mails received). Only there is one discrepancy in GitHub, if you are not watching the repo and is assigned when repo is created you don't get the 'Repo created' e-mail. So they seem to do that in a separate step.

It can seem a bit redundant to send two emails, but it makes sense that there should be no difference if you create and assign in one step or separate. Also most mail clients should handle it well.

@davidsvantesson commented on GitHub (Oct 17, 2019): @guillep2k I tested on GitHub and they do it like you suggest (two e-mails received). Only there is one discrepancy in GitHub, if you are not watching the repo and is assigned when repo is created you don't get the 'Repo created' e-mail. So they seem to do that in a separate step. It can seem a bit redundant to send two emails, but it makes sense that there should be no difference if you create and assign in one step or separate. Also most mail clients should handle it well.

GiteaMirror commented

2025-11-02 05:32:47 -06:00

@guillep2k commented on GitHub (Oct 17, 2019):

@davidsvantesson Whatever the mail subject, if your "assigned" e-mail has always the same structure, it's easier to setup rules and such. So, separate mails seem like win-win to me.

@guillep2k commented on GitHub (Oct 17, 2019): @davidsvantesson Whatever the mail subject, if your "assigned" e-mail has always the same structure, it's easier to setup rules and such. So, separate mails seem like win-win to me.

GiteaMirror commented

2025-11-02 05:32:47 -06:00

@bhalbright commented on GitHub (Oct 18, 2019):

@davidsvantesson as a user I'd prefer to just receive one email, but it makes total sense to follow the github model and as @guillep2k suggested.

@bhalbright commented on GitHub (Oct 18, 2019): @davidsvantesson as a user I'd prefer to just receive one email, but it makes total sense to follow the github model and as @guillep2k suggested.

GiteaMirror commented

2025-11-02 05:32:47 -06:00

@davidsvantesson commented on GitHub (Oct 18, 2019):

I think it shall be separate mails (notifications), it will allow more fine-grained settings of what notifications you want in the future.

@davidsvantesson commented on GitHub (Oct 18, 2019): I think it shall be separate mails (notifications), it will allow more fine-grained settings of what notifications you want in the future.

GiteaMirror referenced this issue

2025-11-02 12:28:36 -06:00

[PR #3982] [MERGED] fix links to prevent 404 after e.g. submitting a faulty form #17180

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3982