Patch to get email notification (with diff) of wiki changes

[pierre.palatin+trac@…]

This is a little patch to get notification, with diff included, of wiki changes. That's implemented against trunk/, revision 1777, as a component. I did'nt know where to put plugins, so I put it in Notify.py (I use NotifyEmail class), but I don't like that too much … (patch follows …)

[pierre.palatin+trac@…]

initial version of wiki changes email notification patch

[ytse@…]

This feature is useful, but get_recipients() looks too simple. It would be a great deal if a user could control the notification by oneself. It may by a watch-list of wiki pages in user's settings or something else…

Let us see how other wikies do it.

[Christopher Lenz]

See also #576.

[Christian Boos]

See also #1459, which discusses a redesign of the ticket CC field. Transposed here, the idea of a nosy list for a Wiki page is also interesting, as anyone who contributes to a Wiki page is potentially interested in what follows-up…

[husted@…]

Let us see how other wikies do it.

Typically, the email address comes from the user profile, rather than being input with the change. The user profile will have settings that determine whether and/or what kind of notifications are issued. For example, sometimes you can opt-out of alerts for your own changes.

Confluence lets you watch a space, so that you can get email alerts for any change to any page in the space. You can also opt-in for a daily change summary.

Moin-Moin also lets you subscribe to pages using a regex. You can use ".*" to subscribe to all changes, or another expression to subscribe to a smaller set. The UI will also add an individual page to the list for you.

Both have a "trivial change" setting you can check. Subscribers can then "opt-out" of trivial changes.

Adding wiki email notification seems like a "must-have" feature for a 1.0 release, since it is now a standard feature of similar products, that many people (including myself) consider essential.

HTH, Ted.

[Christian Boos]

More general notifications certainly need to make it for 1.0, if not sooner.

Alect an me have already discussed a bit about this and the need to make notifications react on change listeners.

[Christian Boos]

Generic change listener interface coupled with notification should be defined. This is somehow related to the propagation of "contexts" of changes that will be introduced at the wiki level.

Adapters to the 0.10 compatible APIs could be written on top of that.

[Noah Kantrowitz (coderanger) <coderanger@…>]

The ​WikiNotification plugin will do this for 0.10.

[jason@…]

Updated patch which applies to trac 0.10

[jason@…]

I have updated the patch to apply cleanly to (and function correctly) with trac 0.10.

[Matthew Good]

Replying to jason@peaceworks.ca:

I have updated the patch to apply cleanly to (and function correctly) with trac 0.10.

It looks like you forgot part of the patch, since it only includes the template and not the associated code changes.

[stelian.iancu@…]

So is this going to svn commit anytime soon?

[Christian Boos]

• the patch attached here will most likely not be integrated in the 0.10 branch, as 0.10.x releases are mostly bug fix releases; they only get minor enhancements that can be easily backported from trunk
• the real fix for this feature (eventually for 0.11) is getting nearer, as I recently made some progresses on the architecture changes needed for this to happen (see TracDev/Proposals /Journaling if you're interested in the details). I'd certainly make use of the contributed patches in some way or another.

[Christian Boos]

#379, #4679 are also duplicates of this ticket.

The new notification architecture is currently being discussed in ​Trac-Dev.

[Christian Boos]

Most probably not for 0.11.

[stoile@…]

I'm very interested in this Feature, too.

[Christian Boos]

Keeping on the long term plan, however this is a very important feature to have, as it makes it possible to have well maintained pages through a micro community of editors interested in that page only.

[Itamar Oren]

I'm confused - what's the difference between this enhancement and #2293?

[Christian Boos]

The mechanism of notification is quite different (push vs. pull to make it short).

#2293 is about RSS readers regularly querying for changes (pull) that happened to a given page (or hierarchy subset), the same way as the timeline RSS feed restricted to the wiki changes would get you the changes for all pages.

Here, we're talking about sending a mail after each change (push), in a similar way we do for ticket changes. However, we probably don't want to reimplement the Cc: system for the wiki, with all its quirks and limitations. We rather need something like nosy list of RoundUp (#8637).

[DMcLean <dmclean@…>]

I would like to see this change as well.

[Peter Suter]

I attached a patch​ that sketches out a possible integration of ​th:AnnouncerPlugin using the new API's from the TracDev/Proposals/AdvancedNotification.

Sorry, this is only an old early draft, not a clean patch and probably doesn't apply etc. I just attach it in case someone is interested in pursuing this and finds it helpful as a rough guideline of what steps are required.

[Ryan J Ollos]

#6069 closed as a duplicate, requesting wiki attachment notifications. Attachment notifications for the ticket system were a fairly simple extension of change notifications, so I think it's reasonable that any implementation of wiki change notifications would include attachment notifications.

[Peter Suter]

new_api_wiki_notifications_v2.patch​ applies to the current trunk. #13041 seems to cause a problem with the child preference panel. With that fix it seems to work in a rudimentary test.

[Ryan J Ollos]

Regarding the child preferences panels, I made a modification to the patch to use prefpanel_has_own_submit = false:

trac/notification/templates/prefs_notification.html

@@ -105 +105 @@
     # endblock head
   </head>
   <body>
-    # set prefpanel_has_own_submit = true
     # block prefpanel
     <h2 id="subscriptions-section">${_("Subscriptions")}</h2>
     #   for distributor, rules in data['rules'].iteritems():
@@ -311 +310 @@
       #   endcall
     </div>
     #   endfor
-    <p class="trac-noscript">
-      <button class="trac-button" type="submit" name="action" value="replace_all">${_("Save changes")}</button>
-    </p>
     # endblock prefpanel
   </body>
 </html>

With that change, the page is rendered like:

The Note: is mislocated - should be at the bottom of the page. It makes me wonder whether the child preference panels should be rendered in prefs_notification.html rather than prefs.html.

Do you have an idea of how to address this?

[Jun Omae]

I think we should add NotificationSystem(env).notify(event) in trac/wiki/web_ui.py rather than using IWikiChangeListener, like trac/ticket/web_ui.py​.

Because page.get_history()[0] in wiki_page_added is dirty and cannot provide who the page is deleted.

    def wiki_page_added(self, page):
        history = list(page.get_history())[0]
        version, time, author, comment = history
        event = WikiChangeEvent("created", page, time, author,
                                comment=comment, version=version)

[Peter Suter]

I made a modification to the patch to use prefpanel_has_own_submit = false

Does the save button still work that way? I think value="replace_all" leads to a different action​ than the default save button​.

The Note: is mislocated - should be at the bottom of the page. It makes me wonder whether the child preference panels should be rendered in prefs_notification.html rather than prefs.html.

Can prefs_notification.html define an Jinja # block for this? (I'm guessing no.)

Or maybe the child preference panel mechanism should be reverted. It seems nobody was really that interested in using it. The notification panel components could be merged, or put into separate top-level panels.

I also wonder if this Wiki Watch Pattern UI is really needed. What is the usecase? I think I would first add some more basic wiki subscribers. (Subscribe to all wiki events. Subscribe to wiki page added events. Subscribe to any wiki events on pages I created / edited.) After that a CC / subscribe / watch button on each wiki page might be nice. (WatchResourcesSubscriber​ from comment:3:ticket:11870 implements that if I remember correctly.)

… like trac/ticket/web_ui.py​.

Yes, probably the entire patch should be checked against how tickets do things. It's currently all based on how the Announcer plugin did things. That may be suboptimal.

[Ryan J Ollos]

Replying to Peter Suter:

I also wonder if this Wiki Watch Pattern UI is really needed. What is the usecase? I think I would first add some more basic wiki subscribers. (Subscribe to all wiki events. Subscribe to wiki page added events. Subscribe to any wiki events on pages I created / edited.) After that a CC / subscribe / watch button on each wiki page might be nice. (WatchResourcesSubscriber​ from comment:3:ticket:11870 implements that if I remember correctly.)

Yes, I think removing Wiki Watch Pattern UI makes sense.

[Ryan J Ollos]

Milestone renamed