[pmwiki-users] Email notification on a page change

[Patrick R. Michaud]

On Mon, Feb 27, 2006 at 12:57:59PM +0100, marco.ferretti at gmail.com wrote:
> Hi all.
> I am a newby, so please forgive me if this question has already been 
> posted/looks stupid.
> I need to send emails to users on a page modification . I saw the MailPosts 
> (http://www.pmwiki.org/wiki/PmWiki/MailPosts) cookbook but I was wondering if 
> there was a way to configure it on a per page subscription : different users 
> subscribe for notifications different pages and get notified *only* about the 
> pages they subscribed to instead of all the pages of the wiki/group.

(Long response with lots of options discussed.)

This has been a long requested feature, but the difficult issue is one
of managing email addresses.  In the general case we really don't
want to simply let authors place email addresses directly into a page, 
because of the various holes it opens up for maliciousness.  (Imagine
a vandal mass-subscribing your email address to a lot of pages.)

Fortunately, we have a large number of (relatively unexplored) new tools
available to help us with this.  The first is that any author can create
a custom RSS feed of pages they happen to be interested in.  
For example, if I want to watch the Cookbook.LightSkin, PITS.00565,
and Cookbook.Cookbook pages, I can create a page (e.g., Pm.Profiles)
containing the markup:

    Pages I'm watching:
    * [[Cookbook.LightSkin]]
    * [[PITS.00565]]
    * [[Cookbook.Cookbook]]

and then to get an RSS feed of just those pages with the most recently
modified pages appearing first, I can do:

    http://www.pmwiki.org/wiki/Profiles/Pm?action=rss&order=-time

This also gives me a central place to manage my page subscriptions,
rather than having to visit each page and subscribe/unsubscribe myself
on each one.

Someone can probably even come up with a recipe that provides a
"subscribe/unsubscribe page" markup that can go into templates/
headers/pages to provide visitors with a convenient link for
adding/removing pages to the watch list.

The upside of an RSS-based approach is that there are a lot of tools
in existence for managing and doing wonderful things with RSS feeds.
The downside is that RSS uses a "pull" model -- requiring that the
feed be frequently checked -- whereas many people would like a "push"
model whereby I'm sent a message as soon as the change occurs.

But we still have some options here.  With the recent improvements
to ".pageindex", finding backlinks is now fairly quick.  So, when
an author updates a page, it's fairly simple for PmWiki to locate
all of the watch lists that are referencing the newly-updated page and 
do something with them, like send an email to the person who
created the watch list.

Which just brings us back to the problem of safely handling email
addresses.

One approach might be to have PmWiki maintain a "Site.ApprovedMail"
page, something like what it currently does for Site.ApprovedUrls.
Then we could have watchlist pages with a directive that
says "send email to xyz at example.com whenever any of the pages on
this list are updated", and PmWiki would verify that xyz at example.com
is on the ApprovedMail page prior to sending the message.

For non-administrators (or people without write access to the
ApprovedMail page), getting an address onto the page would require
verification of the address -- i.e., PmWiki would send a "confirmation
link" via email to a potential subscriber; the address is then added
to the ApprovedMail page only when a valid confirmation link is
followed.

It also seems to me that keeping track of watch lists and email addresses
is very closely related to managing user preferences, as in the
Cookbook.UserConfigurations recipe.  So, instead of a central list
of valid email addresses, perhaps we just need a way to attach 
verified email addresses to user preference pages containing watchlists.

At any rate, that's sort of where things stand.  Until we have a solid
solution for safely handling email addresses, subscribed email
notifications of page changes remains a bit of a challenge.

Pm