Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send Email to Assignee on Assignment #8233

Closed
jag3773 opened this issue Sep 18, 2019 · 13 comments · Fixed by #8546
Closed

Send Email to Assignee on Assignment #8233

jag3773 opened this issue Sep 18, 2019 · 13 comments · Fixed by #8546
Labels
type/enhancement An improvement of existing functionality

Comments

@jag3773
Copy link

jag3773 commented 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 #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.

@HenrikBengtsson
Copy link
Contributor

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.

@lunny lunny added the type/enhancement An improvement of existing functionality label Sep 19, 2019
@davidsvantesson
Copy link
Contributor

@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.

@bhalbright
Copy link
Contributor

@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.

@jag3773
Copy link
Author

jag3773 commented 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!).

@guillep2k
Copy link
Member

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

@davidsvantesson
Copy link
Contributor

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

@guillep2k
Copy link
Member

@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.

@davidsvantesson
Copy link
Contributor

@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"?

@guillep2k
Copy link
Member

@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.

@davidsvantesson
Copy link
Contributor

@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.

@guillep2k
Copy link
Member

@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.

@bhalbright
Copy link
Contributor

@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.

@davidsvantesson
Copy link
Contributor

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

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants