create new tag
, view all tags

Customizable Email Notification

I didn't find a topic that covered email change report customization overall. I did however find topics on CustomizableEmailNotificationInterval. This page should probably be pointed to by ChangesThread.


The terms I use are:

what is displayed in the email for a topic. E.G. is an HTML attachment included? Are diffs generated with the topic? Is the file included in the email?
how often should the notification occur? See CustomizableEmailNotificationInterval for a discussion of this.
a way of determining what topics should be listed in the changes email. This includes:
  • list minor or major changes
  • don't show metadata changes
  • don't show renames/moves
  • show only selected topics
  • show only new topics
  • show all topics (current default)


My proposed mechanism has three parts:

  1. The user's page defines the format, selection and interval. Variables define the site default for the user and the default on a particular web. These variables just sit there unless...
  2. The user places an entry in the webnotify page enabling notifications. Since the WebNotify page provides a mapping to TWiki usernames, finding the preferences page and analyzing it shouldn't be that bad. (Then again you have to enter your email into the WebNotify page when it is available from the user page, so maybe it was too expensive.) Having no WebNotify page to act as an index would require parsing all User pages for notification info. My assumption is that there are more users than people who are to be notified for a particular web.
  3. Optionally (depending on what the selection mechanism is) the user can store metadata in a topic that will cause a change notification to be sent if that topic is changed.


  1. Options for notification for a web can be set on the user page with a series of variables. The overall site notification variable is NOTIFY and it determines what is sent and how it is sent.

    A {WEBNAME}_NOTIFY can override this and provide different values for a specific web. E.G.

     NOTIFY = PerTopic NewTopic DiffFormat ExcludeRename
     CODEV_NOTIFY = NoExcludeRename ExcludeMinor StandardFormat ExcludeHTML
     PLUGINS_NOTIFY_INTERVAL = 8,10,12,14,16:::2-6

By default this would give me notifications of topics I am following, notifcation of any new topics, it would include diffs of the topics and would not notify me if a topic is renamed. I would be notified every two days. For changes in the codev web, I would get notifications of topics I am following, notifcation of any new topics, I would be notifed if a topic changed name, I would not be notified if the change was a minor one, I would receive the report in the standard TWiki format, but without the HTML attachment. I would also be notified once a day. For the plugin's web, I get notified every two hours from 8 amto 4 pm on monday (day two) to friday (day 6) (hey just gotta keep up with those new plugins 8-).)


Proposed options are listed below. Orthagonal options support the No form of the option to disable the function:

Only send notification if I am listed in the notify metadata in the topic.
Only send notification if this topic is new since the last time I was sent information.
(the default) send information about all topics.
don't sent info on renamed topics.
don't send info if it is a minor change.
looks like the current email notifications
adds difference info to email so you can see what has changed without having to go to the web.
don't put a second mime part consisting of an html attachment in the message.
Generate only one email for all webs that have MultiWeb set. If NoMultiWeb is set, generate a separate email for that web. If you use MultiWeb the interval is determined by the NOTIFY_INTERVAL variable setting. Web specific interval settings are ignored.


This allows a series of features to be added as needed and the selection mechanism should (hopefully) stay the same. The selection of the feature is added to to the NOTIFY variable and any additional arguments can go into a NOTIFY_{ARG} variable. E.G. a plugin that allows a word diff (See WordDiff) format may have:

     NOTIFY = PerTopic NewTopic WordDiffFormat ExcludeRename
     NOTIFY_WORDDIFF_PRE_INSERT= :: insert here ::
     NOTIFY_WORDDIFF_POST_INSERT= :: end insert ::

Changes to code

Some of these changes may already be in place. I don't have shell access to a twiki site at the moment to verify the current operation, and the docs don't have this level of detail yet.

To make my proposal feasable, I think the majority of the work is in mailnotify, but a few other changes are needed.

Per Topic Registration

I think it is cleaner if each topic contains metadata that records a users request to be notified if the page changes. Now should it be true twiki metadata, or will an editable hidden data block:

<!--- subscribe for notification of changes to this page here just add your WikiName on a new line in alphabetical order JohnRouillard --> suffice? Then again this is what the metadata was supposed to eliminate correct?

What about alternative interfaces to this data? E.G. links on the bottom bar for subscribe to page and unsubscribe from page to add/delete the notification information. This could be done with a modified version of the edit or savecomments cgi's.

I did play around with the idea of allowing the user to specify a default subscribe/unsubscribe status for new pages that matched some criteria. It would automatically add the user's name to the subscription info. However specifing a search as a variable just seemed too cumbersome. If the user want's this they can set up a search on their userpage and find pages they aren't subscribed to.

Also I think that the NewTopic option will allow the user to see new pages and if s/he want to be notified that can go to the page and subscribe to it.

Recording changes

The current code that records changes will have to record the type of change (major/minor/rename) so that a selection can be made against this data.


Plugins will have to be exended to support mailnotify. I suggest the same mechanism be used as in TWiki this way the ability to disable plugins per web etc doesn't have to be recoded. These notify plugins won't have any html rendering capability so insidePREHandler and outsidePREHandler won't be used, but functions like renderNotify will be. Also persistent data such as a file that contains:
 UserName LastNotificationDate otherdata
will be made available though a notifcation plugin API.

How closely should this be tied into the current plugin mechanism? What are the effects of overloading the plugins to support both notify and TWiki rendering? Should plugins return class (Twiki, notify) information when they are initialized to allow TWiki to not waste time checking the Notify Plugins for html handler functions?


Will have to be rewritten to do the following for each web:

  • load the last change reported information file
  • load the file that records which topics have changed
  • load the WebNotify topic
  • for each user on the WebNotify page
    • scan the user page to obtain the *NOTIFY* variable definitions
    • check to see if it is the correct time to generate a report for this user
    • run the plugins/core code to select the Topics to be reported
    • for each topic
      • run the plugins/core code to format the message entry
    • send the email (or hold it if multiple webs are being reported)
    • update the last change reported info

To think about

Currently I have the per topic notify metadata including the topic in the changes notification. Should there also be support for excluding the change notifcation??

The user times are probematic. There are so many ways of specifying the times to generate reports. E.G. I want one generated at 7AM and every hour till close of business. Having emails generated when I can't process them is silly. Using absolute times means that I have to compute the times on the server and use those to get the notification that I want.

Again weekend vs. weekday reporting is an issue (see CustomizableEmailNotification) so how do we specify it?.

Should absolute time specs (e.g. 7,9,11,13,15 on mon-fri) be generated using a cron job like:

   0 7,9,11,13,15 * * 1,2,3,4,5 (cd /home/twiki/bin; ./mailnotify -q UserName )

What things do people want in email notifcation that the above doesn't support?

It this mechanism too difficult for novice/non nerds to understand and use?

Whew. This is longer that I thought it would be. Please insert:

  • Quips
  • Comments
  • Evasions
  • Questions
  • Answers

-- JohnRouillard - 28 Dec 2001


Cool. As I'm sure you've already read, at least in part, there's a ton of stuff in Codev on various aspects of changes notification: being alerted to an updated topic; personalized see-it-once change highlighting; making it easy to zero in on actual changes, down to a single word or letter;... If there is one pivotal user-acceptance factor for any sophisticated T/Wiki, changes notification is it.

For one thing, actually "editing anywhere" - inserting comments where they make most sense in a discussion, as opposed to simply appending - is seriously discouraged by not being able to immediately scan and locate new entries anywhere on a page. Perhaps this feature alone would change the way some Wikis are used - that alone would make a big difference in communication style...

BTW, checking ChangesProject in the WebForm is perfect. Once the old topics, some already gathered in ChangesThread, are tagged, it'll be easy to list them, and FUN to update ChangesProject and see what emerges!

-- MikeMannix - 28 Dec 2001

One simple but effective solution

I just wanted to point to an implementation of CustomizableEmailNotification on another wiki that I think would be great. The site is OrgPatterns:OrgPatterns and at the bottom of each page, there is a link that says "RegisterInterest in this page." Clicking that, you are presented with these simple instructions:
You can track changes to the previous page on a page of your choosing. You want 
notifications to appear at the bottom of what page? 
We suggest something like JimCoplienRecentChanges. 
You can also choose to receive notification by mail with something like mailto:JOCoplien@cs.com. 
Press me to register the interest in changes to this page: send 
Without getting too much involved with all the possible options, this system would meet 90% of my needs for CustomizableEmailNotification. Anybody want to comment of what it would take to implement it?

-- LynnwoodBrown - 25 May 2002

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2008-09-17 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.