-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
AutoSubscribe to Issue when create or comment to it #9535
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
AutoSubscribe to Issue when create or comment to it #9535
Conversation
4e5df52
to
e8e1d17
Compare
a511262
to
c8bcaf0
Compare
c8bcaf0
to
b318aa6
Compare
also look at #9118 |
39dc312
to
7ff8521
Compare
0d2ca3f
to
2d7e067
Compare
Codecov Report
@@ Coverage Diff @@
## master #9535 +/- ##
========================================
Coverage ? 43.7%
========================================
Files ? 587
Lines ? 81204
Branches ? 0
========================================
Hits ? 35493
Misses ? 41313
Partials ? 4398
Continue to review full report at Codecov.
|
7f25bb4
to
d667d6f
Compare
I think now it is more a |
c7c504f
to
d9ce9f9
Compare
This reverts commit 060e28b.
@guillep2k would be nice if you had time to look at it :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My question is still standing: why are auto-watch subscriptions needed on issues when participants should be automatically notified anyway? Am I missing something? 🤔
gitea/modules/notification/mail/mail.go
Lines 42 to 44 in 5dc634d
if err := mailer.MailParticipantsComment(comment, act, issue); err != nil { | |
log.Error("MailParticipantsComment: %v", err) | |
} |
gitea/modules/notification/mail/mail.go
Lines 70 to 72 in 5dc634d
if err := mailer.MailParticipants(issue, doer, actionType); err != nil { | |
log.Error("MailParticipants: %v", err) | |
} |
etc.
I know that this doesn't cover the dashboard feed (action
table), but subscribing the participants will make the code linked above redundant. Maybe we should remove that code and let subscriptions handle the notifications? If so, we'd need to auto-subscribe all participants in the migration step.
I would prefere if a action witch triger a email notification also create a notification for ui - this inconsistency is anoing for me |
I understand that, but now there are two paths in which participants will be receiving email notifications: via ⑴ I say "carefully" because there are several subtleties in how the emails are tailored for each notification type. |
@guillep2k I'll split up changes of this pull to make independent desicions about how UI & Mail Notifications are unifiedy and how to make this configurable |
since #10473 was merged ... should we still migrate db to use integer instead of bool ( move from is_watching to mode colum) so we can add different modes in future - if so I'll remove IssueWatchModeAuto for now and rebase? EDIT: modesl like: "notify only on state-change" & "ignore mentions too" ... |
👍 for rebase and migrate |
I don't think this is needed after your other PR was merged. Unless there's something else I'm missing. 😁 |
Fix #8243 auto subscribe issue on interact
try to fix issue #9233(this is a independend bug)close #8852
add IssueWatchMode type
correct Tests
add Tests
remove race when create/update IW
migration