RFE: Email notification mechanism

Should be users able to register into whole forum or simple topic? I would prefer to make configurable option if e-mail should be posted to author, because ticket system is posting to author too and this behaviour suits me.

I think logic like the tickets is the simplest functional approach: when a new reply is posted to a topic, email a notificaton all topic posters. (be careful not to email once for each message, this will probably cause multiple messages to sevral people). you can use either sender email (as registered in the system), or the user name, if the user entered an email there.

registered email.

That would be a very useful feature!

Thanks for this plug-in - we already find it very useful for our workgroup, but the addition of notifications would be a huge plus - and FWIW, I think the per forum notification would be the most useful for us: allowing a user to 'subscribe' to a forum, and get an email whenever there is a new posting (a new topic, or a reply to an existing topic).

(That might usefully be coupled with a per-topic subscription as well - or even a scenario where anyone who has actively posted to a topic, but isn't already subscribed at the forum(/topic) level, gets notifications for that topic anyway...)

And also, as suggested above, I'd like the ability for the system to pull the email address out of the 'user name' field, as we have a username=email address convention for simplicity.

I'll try to implement e-mail notification behavior as close to trac ticket e-mail notification as possible with respectation of desired features. Unfortunatelly I don't have much time theese days since school year has started. You'll have to wait or find someone who wants to implement this and I'll arrange repository permission to him/her.

I would salute this feature!

Erwin

I implemented a simple e-mail notification mechanism. At the moment, mails are only sent to addresses listed in smtp_always_cc and smtp_always_bcc in the notification settings in trac.ini. Please try the notification.patch (this is my very first python code, so I'm glad to hear, how things can be improved).

I would suggest to add an extension point IDiscussionChangeListener to the discussion core component, and put the email notification in it's own component.

To allow the user to select, for which forums/forums groups/topics/messages he wants to receive notifications, a mechanism similar to that used in WikiNotificationPlugin would be great. Perhaps it is possible, to create a generic NotificationPlugin? (to provide a common user interface for notifications), which can be used for all kind of user selected notifications (wiki, discussion, tickets ...).

Replying to imme:

I implemented a simple e-mail notification mechanism. At the moment, mails are only sent to addresses listed in smtp_always_cc and smtp_always_bcc in the notification settings in trac.ini. Please try the notification.patch (this is my very first python code, so I'm glad to hear, how things can be improved).

Great work, I could look at your patch closely later because I'm pretty busy these days. I'm plannig to start working ton DiscussionPlugin again after New Year, but if you want I can apply your patch to repository now.

I would suggest to add an extension point IDiscussionChangeListener to the discussion core component, and put the email notification in it's own component. To allow the user to select, for which forums/forums groups/topics/messages he wants to receive notifications, a mechanism similar to that used in WikiNotificationPlugin would be great. Perhaps it is possible, to create a generic NotificationPlugin? (to provide a common user interface for notifications), which can be used for all kind of user selected notifications (wiki, discussion, tickets ...).

Write common notification plugin would be right way but I'm not sure if such interface isn't planned for some next Trac version. I haven't work with Trac for such long time that I don't know what is new and I even forgot a lot of Trac coding isues :-(.

no hope on having any progress on it?

please, don't let this great plug-in die.

Thank you,
armando

I asked if I should apply that patch without any changes or better implementation of it immediatelly, but there was no answer. I'd like to implement it more generally and there is promissed general notification sytem in 0.12 (perhaps). I'm trying to work on this plugin but there is a lot of other things more important, so sorry that its development stays for now.

If the patch works and people are waiting for a notification mechanism, you can apply the patch to the repository.

Replying to imme:

I implemented a simple e-mail notification mechanism. At the moment, mails are only sent to addresses listed in smtp_always_cc and smtp_always_bcc in the notification settings in trac.ini. Please try the notification.patch (this is my very first python code, so I'm glad to hear, how things can be improved).

I took a closer look on your patch and it needs some changes and extensions as you suggested. Some of them I make today and I hope that I'll do the others in next few days.

I would suggest to add an extension point IDiscussionChangeListener to the discussion core component, and put the email notification in it's own component. To allow the user to select, for which forums/forums groups/topics/messages he wants to receive notifications, a mechanism similar to that used in WikiNotificationPlugin would be great. Perhaps it is possible, to create a generic NotificationPlugin? (to provide a common user interface for notifications), which can be used for all kind of user selected notifications (wiki, discussion, tickets ...).

Unfortunatelly I can't get on WikiNotificationPlugin's homepage so I can react on that but for now, I agree. Of course that generic notification plugin would be great but as I said there is planned this in Trac itself. It should be called IChangeListener so let's be suprrised :-) For now is IMHO way to do that you suggested in your patch sufficient.

I've submitted basic implementation in changeset 1987. For now it only notifies about topic and reply creation and using smtp_always_cc and smtp_always_bcc as a recievers. Next step is to modify Web UI to support recievers specification for concrete forums, and topics. I think that notifying about topic and reply creation and modification is sufficient but if you think that you would use other notifications, please, let me know.

First of all thank you for your support.

The problem is that I use smtp_always_cc and smtp_always_bcc for other purposes. They cannot receive notifications from the Discussion plug-in.

Without modifying the Web UI, it will be nice to have notifications for all the authenticated users that partecipate in a topic getting their email address form the DB.

Thanks again,
armando

I considered this solution too but I'd like to add CC field as in tickets to each topic and forum for moderators and unauthenticated users. Off course author of topic and all contributors will be notified by default but there will option in trac.ini to disable this behaviour and send only to users in CC field.

What I need, specifically, is for ordinary authenticated users (or unauthenticated users who have set their email address in Preferences to see a checkbox or other binary indicator that tells them whether they are currently monitoring the conversation and gives them the opportunity to change that setting. Nobody but administrators or moderators should see and be able to modify the whole Cc: list.

Ok, that is how is notification handled in many discussion systems. I can make it like that. Do you still want to use always_notify_owner, always_notify_reporter and always_notify_updater from trac.ini?

it will be nice that plus smtp_always_cc and smtp_always_bcc. Regards,

is this helpful improvement still in development or was it put on ice? A field would be quite fine, like the CC field in normal trac tickets; simply the usernames separated by commas and available for both topics and forums.

Replying to Blackhex:

Replying to imme:

I implemented a simple e-mail notification mechanism. At the moment, mails are only sent to addresses listed in smtp_always_cc and smtp_always_bcc in the notification settings in trac.ini. Please try the notification.patch (this is my very first python code, so I'm glad to hear, how things can be improved).

I took a closer look on your patch and it needs some changes and extensions as you suggested. Some of them I make today and I hope that I'll do the others in next few days.

I would suggest to add an extension point IDiscussionChangeListener to the discussion core component, and put the email notification in it's own component. To allow the user to select, for which forums/forums groups/topics/messages he wants to receive notifications, a mechanism similar to that used in WikiNotificationPlugin would be great. Perhaps it is possible, to create a generic NotificationPlugin? (to provide a common user interface for notifications), which can be used for all kind of user selected notifications (wiki, discussion, tickets ...).

Unfortunatelly I can't get on WikiNotificationPlugin's homepage so I can react on that but for now, I agree. Of course that generic notification plugin would be great but as I said there is planned this in Trac itself. It should be called IChangeListener so let's be suprrised :-) For now is IMHO way to do that you suggested in your patch sufficient.

My WikiNotificationPlugin has been updated and the website is once more online, you probably tried to reach it on one of the times where I migrated my server.

I too miss a general notification system where one could attach our code on not have to write 80% of the notification code.

I'm also very interested on an enhanced notification mecanism. Perhaps, for now, al least all moderators of the specific forum which got a new post should be notified also? There might not be an interest of having a moderators email address in smtp_always_(b)cc, yet allow him to be notified of forum posts which he's a moderator?

Do note that duplicated email addresses are removed before sending the email address in trac's notification code, so duplication is not an issue with the above suggestion...

(Pririty changed to high since an efficiant usage is impossible without a notification subsystem)

I really think this plugin is great, but it lacks badly of a notification system, thus I would like to see the priority be changed to High.

So there seem to be various requirements in the community: General notification, general forum notification, topic notification and thread notification - but I think this could be generalized:

'/*' would be a general notification '/1/*' would be a general notification in forum #1 '/1/34/*' would be a notification for topic #34 in forum #1

Given that a topic is the same object type as a message within a message type, '/1/89/*' could be a thread notification if message #89 is within topic #34. But for resolving purposes, it might be better to go all the way down the thread path, i. e. to set '/1/34/89/*' in this case. '/1/34/*' and '/1/34/89/*' could be resolved against each other, either at notification setup time or at notification deployment time, depending on the system architecture.

It might be ok to utilize an existing notification system like WikiNotificationPlugin, or better AnnouncerPlugin, since the latter supports wildcards already.

I suppose you know that there is a temporary notification support. It only lacks possibility of forum based notification and inviting currently not participating users to discussion. It also needs futher refactoring of certain parts. I hope I'll progress with it in the next few months.

I'm not sure what do you mean by the '/1/34/89/*' syntax in a notification context? Note that I'll change the URL request paths of discussion objects to '/discussion/forum/<id>' etc. to fix problem with topic move in RSS feeds.