Edgewall Software
Modify

Opened 19 years ago

Last modified 3 years ago

#1660 new enhancement

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

Reported by: pierre.palatin+trac@… Owned by:
Priority: normal Milestone: 1.7.1
Component: notification Version: devel
Severity: major Keywords: patch notification email nosylist
Cc: luca.ceresoli@…, stoile@…, itamarost@…, tiago@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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 …)

Attachments (5)

wikimail-patch-1.diff (4.3 KB ) - added by pierre.palatin+trac@… 19 years ago.
initial version of wiki changes email notification patch
wikimail-patch-against-0.10.diff (4.0 KB ) - added by jason@… 17 years ago.
Updated patch which applies to trac 0.10
new_api_wiki_notifications.patch (12.3 KB ) - added by Peter Suter 9 years ago.
new_api_wiki_notifications_v2.patch (12.6 KB ) - added by Peter Suter 6 years ago.
Screen Shot 2018-06-13 at 02.12.44.jpg (49.9 KB ) - added by Ryan J Ollos 6 years ago.

Download all attachments as: .zip

Change History (44)

by pierre.palatin+trac@…, 19 years ago

Attachment: wikimail-patch-1.diff added

initial version of wiki changes email notification patch

comment:1 by ytse@…, 19 years ago

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.

comment:2 by Christopher Lenz, 18 years ago

Component: generalwiki

comment:3 by Christopher Lenz, 18 years ago

See also #576.

comment:4 by Christian Boos, 18 years ago

Keywords: notification email added

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…

comment:5 by husted@…, 18 years ago

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.

comment:6 by Christian Boos, 18 years ago

Milestone: 1.0
Owner: changed from Jonas Borgström to 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.

comment:7 by Christian Boos, 17 years ago

Milestone: 1.00.11
Priority: normalhigh

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.

comment:8 by Noah Kantrowitz (coderanger) <coderanger@…>, 17 years ago

The WikiNotification plugin will do this for 0.10.

by jason@…, 17 years ago

Updated patch which applies to trac 0.10

comment:9 by jason@…, 17 years ago

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

in reply to:  9 comment:10 by Matthew Good, 17 years ago

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.

comment:11 by stelian.iancu@…, 17 years ago

So is this going to svn commit anytime soon?

comment:12 by Christian Boos, 17 years ago

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

comment:13 by Christian Boos, 17 years ago

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

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

comment:14 by Christian Boos, 17 years ago

Milestone: 0.110.12

Most probably not for 0.11.

comment:15 by Piotr Kuczynski <piotr.kuczynski@…>, 16 years ago

Component: wiki systemnotification

comment:16 by Luca Ceresoli <luca.ceresoli@…>, 15 years ago

Cc: luca.ceresoli@… added

comment:17 by stoile@…, 15 years ago

Cc: stoile@… added

I'm very interested in this Feature, too.

comment:18 by Remy Blank, 14 years ago

Milestone: next-major-0.1Xunscheduled

comment:19 by Christian Boos, 14 years ago

Milestone: unschedulednext-major-0.1X
Priority: highnormal
Severity: normalcritical

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.

comment:20 by Itamar Ostricher, 13 years ago

Cc: itamarost@… added

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

comment:21 by Christian Boos, 13 years ago

Keywords: nosylist added

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

comment:22 by DMcLean <dmclean@…>, 13 years ago

I would like to see this change as well.

comment:23 by tiago@…, 13 years ago

Cc: tiago@… added

comment:24 by Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

by Peter Suter, 9 years ago

comment:25 by Peter Suter, 9 years ago

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.

comment:26 by figaro, 8 years ago

Keywords: patch added
Severity: criticalmajor
Summary: Patch to get email notification (with diff) of wiki changes Patch to get email notification (with diff) of wiki changes

comment:27 by Ryan J Ollos, 7 years ago

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

Last edited 7 years ago by Ryan J Ollos (previous) (diff)

by Peter Suter, 6 years ago

comment:28 by Peter Suter, 6 years ago

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.

by Ryan J Ollos, 6 years ago

comment:29 by Ryan J Ollos, 6 years ago

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

    commit b8c7372978014d9da0c6d917afcd2aacc8dc372e
    Author: Ryan J Ollos <ryan.j.ollos@gmail.com>
    Date:   Mon Jun 11 21:36:43 2018 -0700
    
        Move submit button to bottom of page
    
    diff --git a/trac/notification/templates/prefs_notification.html b/trac/notification/templates/prefs_notification.html
    index 717026bf4..fdc543b91 100644
    a b  
    105105    # endblock head
    106106  </head>
    107107  <body>
    108     # set prefpanel_has_own_submit = true
    109108    # block prefpanel
    110109    <h2 id="subscriptions-section">${_("Subscriptions")}</h2>
    111110    #   for distributor, rules in data['rules'].iteritems():
     
    311310      #   endcall
    312311    </div>
    313312    #   endfor
    314     <p class="trac-noscript">
    315       <button class="trac-button" type="submit" name="action" value="replace_all">${_("Save changes")}</button>
    316     </p>
    317313    # endblock prefpanel
    318314  </body>
    319315</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?

Last edited 6 years ago by Ryan J Ollos (previous) (diff)

comment:30 by Jun Omae, 6 years ago

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)

comment:31 by Peter Suter, 6 years ago

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.

Last edited 6 years ago by Peter Suter (previous) (diff)

in reply to:  31 comment:32 by Ryan J Ollos, 6 years ago

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.

comment:33 by Ryan J Ollos, 5 years ago

Milestone: next-major-releasesnext-dev-1.5.x

comment:34 by Ryan J Ollos, 4 years ago

Milestone: next-dev-1.5.x1.5.1
Owner: set to Ryan J Ollos
Status: newassigned

comment:35 by Ryan J Ollos, 4 years ago

Milestone: 1.5.11.5.3

comment:36 by Ryan J Ollos, 3 years ago

Milestone: 1.5.31.7

comment:37 by Ryan J Ollos, 3 years ago

Milestone: 1.71.7.1

Milestone renamed

comment:38 by Ryan J Ollos, 3 years ago

Milestone: 1.7.1
Owner: Ryan J Ollos removed
Status: assignednew

comment:39 by Ryan J Ollos, 3 years ago

Milestone: 1.7.1

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.