Patch #23278
closed
When creating issues by receiving an email, watchers created via CC in the mail don't get an email notification
0%
Description
When creating issues by email via the redmine:email:* rake tasks, users mentioned in the CC field of the email get added as watchers to the created issue. However, these watchers don't get a notification mail about the creation of the new issue.
The reason for that is rather complex and doves deep into the ActiveRecord bowels. To make things short, the list of recipients for a notification mail is gathered by acts_as_watchable from the watcher_users attribute which is defined as
has_many :watcher_users, :through => :watchers, :source => :user, :validate => false
Now, when adding new watchers to an existing object (as is done in MailHandler#add_watchers, resp. Redmine::Acts::Watchable#add_watcher, the cache of the watcher_users relation which is maintained by Rails is not updated. As such, when querying @issue.watchers, you get the correct list of watchers but @issue.watcher_users still reflects the state before the watchers were added.
Thus, while the watchers get added correctly to the database, they will be ignored during the actual mail receive action and will thus not receive any initial notification.
At Planio, we use the attached patch to fix this behaviour and send the initial notifications to all watcher users on issue creation.
Files
Updated by Jean-Philippe Lang almost 8 years ago
- Category set to Email receiving
- Status changed from New to Resolved
- Assignee set to Jean-Philippe Lang
- Target version set to 3.2.4
Yes, we can see that by removing issue.reload in MailHandlerTest#test_add_issue_should_add_cc_as_watchers.
I've committed a different fix in r15609 that uses #reset instead of #reload in #add_watcher and #remove_watcher instead of forcing a reload before sending the notification.
Please let me know if there is anything wrong with that.
Updated by Holger Just almost 8 years ago
Using reset instead of reload should result in the exactly the same result since Rails will then autoload the association on next access anyway. Using reset will just be a bit faster if we haven't updated the association since we are saving some SQL queries. Thus, a big +1 from me. Thanks, Jean-Philippe!
Updated by Jean-Philippe Lang almost 8 years ago
- Status changed from Resolved to Closed
Thanks for your feedback Holger, I've merged the fix.
Updated by Victor Campos almost 8 years ago
Jean-Philippe Lang wrote:
Thanks for your feedback Holger, I've merged the fix.
Hi,
reset shoundn't happen after add/remove?
Updated by Holger Just almost 8 years ago
Victor Campos wrote:
reset shoundn't happen after add/remove?
The reset method just clear the cache of the association proxy but does not actually reload the association. As such, the only requirement is that the reset happens before the watcher_users association is accessed next time. This does not happen when adding the watcher itself. As such, resetting the association before adding the watcher is fine.
Updated by Victor Campos almost 8 years ago
Holger Just wrote:
Victor Campos wrote:
reset shoundn't happen after add/remove?
The reset method just clear the cache of the association proxy but does not actually reload the association. As such, the only requirement is that the reset happens before the
watcher_usersassociation is accessed next time. This does not happen when adding the watcher itself. As such, resetting the association before adding the watcher is fine.
Thx =)
Updated by Joaquim Homrighausen about 7 years ago
Does this in any way change the handling of watchers not being added from the FROM: field of an email-imported issue?
Updated by Toshi MARUYAMA almost 7 years ago
Joaquim Homrighausen wrote:
Does this in any way change the handling of watchers not being added from the FROM: field of an email-imported issue?
AFAIK, FROM become author.
If you mean CC not FROM, please create new feature issue.