create new tag
, view all tags
Please read ConsolidateNotification and MailerContrib

It would be great if we could add people to a topic (similar to an attachment) which are immediately notified if this topic changes.

-- TWikiGuest - 06 Sep 2000

TWiki has an "asynchronous" notification mechanism; it runs periodically and sends an email of change notification to interested parties. If you set the period for which cron runs this to a suitably small amount of time, it approximates "immediately".

-- PaulReiber - 02 Jan 2001

True, but my users only want to be notified if a particular page (that they decide is important) changes. The current EmailNotification is only very similar to the RecentChanges page.. -- SvenDowideit - 30 Jan 2001

Two ways of doing it. Both require some slight modifications to the save script. i) List of pages on the Main.User's page, ii) some meta-information like:


The first is slow, requires a walk of the User list, the second needs to be done in a way the requires no actual 'edit' of the page. Probably the second method with a new interface to edit the 'notify list' meta-information would be needed to do this nicely.

-- NicholasLee - 07 Sep 2000

I implemented this using < ChangeNotify >WikiUserName,email@address.net< / ChangeNotify> and then my code looks at the list and it replaces any WikiName with the email address listed on the WikiPage (placed there by the UserRegistration)

see below

....snip from save.pl
    &wiki::saveTopic( $topic, $text, $saveCmd );

    &wiki::notifyTopicChange( $topic, $text, $saveCmd );

   my ( $new_url ) = &wiki::viewUrl( $topic );

.......snip from wiki.pm
# =========================
sub notifyTopicChange
    my( $topic, $text, $theRemoteUser ) = @_;

   if ( $text =~ /(.*)<\/ChangeNotify>/gi )
      if ( $1 )
         my $EmailTo = $1;
         my $oldTo = $EmailTo;
         my $invalidAddresses;
#need to scan through the csv's to see if there are any WikiNames and replace them with the email address
         ($EmailTo, $invalidAddresses) = getEmail($EmailTo);

          my $tmpl = &wiki::readTemplate( "NotifyChange" );
#          my $text= &wiki::readTopic( $topic );

         if ( $invalidAddresses )
            $tmpl = $tmpl."\nThere are some invalid addresses \n\n".$invalidAddresses;
            $tmpl = $tmpl."\n\nPleases help by passing this info on to the people listed,\n or to peter09@thoeny.org";
            $tmpl = $tmpl."\nThese are the VALID addresses \n\n".$EmailTo;

         $tmpl =~ s/%EMAILTO%/$EmailTo/g;
         $tmpl =~ s/%WIKIPAGE%/$topic/g;
         $tmpl =~ s/%USERCODE%/$userName/g;

         my ($userEmail, $duds) = getEmail($userName);
         if ( $userEmail )
            $tmpl =~ s/%FROM%/$userEmail/g;

         $text = &wiki::handleCommonTags( $text, $topic );
#         $text = &wiki::getRenderedVersion( $text );

          $tmpl = &wiki::handleCommonTags( $tmpl, $topic );
          $tmpl =~ s/%TEXT%/$text/go;


# =========================
sub getEmail
    my( $names ) = @_;

#   $names = &wiki::getRenderedVersion( $names );  # this should get Vars out..

   my $email = "" ;
   my @processedEmails = ();
   my @invalidAddresses = ();
   my $invalids = "";

   my @Emails = split(/[,; \t]+/, $names);

   foreach (@Emails)
#      if ( not /$wiki::userName/ )
         if ( topicExists( $wiki::webName, $_ ) )
            my $text = readTopic( $_ );
            $text =~ /Email: (.*)/gi ;
            $_ = $1;
         # there is no EMail: entry on the home page, or no home page
         if ( /(.*)\@(.*)/ )
         {#only want valid addresses...
            push(@processedEmails, $_);
            #$email = $email."\@not.there";

#$invalids = $invalids."**".$_;

            push(@invalidAddresses, $_); # so the peter09@thoeny.org gets a bounce msg
   $names = join(',',@processedEmails);
   $invalids = join(' | ',@invalidAddresses);
   return ($names, $invalids);
-- SvenDowideit - 29 Dec 2000

It would be cool to have the subscription information stored in a META field on each topic. Once TWiki knows who a user is they could click on a 'Notify Me' button for the topic that sends them any content changes.

Coupled with the SubmitTopicByEmail work that my team is working on this would provide round-trip email integration.

-- MartinCleaver - 01 Nov 2001

I don't really agree :() i'm starting to think the whole, lets hide that info in the meta data idea is bad .... it seems to stuff up the simple wiki nature of being able to edit info in the edit pane..

-- SvenDowideit - 02 Nov 2001

Well, what's missing is a Meta data editor pane...

-- MartinCleaver - 03 Nov 2001

i hope you meant to add a smile or somthing.....

-- SvenDowideit - 04 Nov 2001

Sorry, I guess I was somewhat cryptic! I mean that there needs to be a way of seeing and setting the meta data for each page. In fact it would be really easy to implement - just using the forms system we already have in place. We could have a pop up window to show it. Also:

  • Certain fields could be protected.
  • The SET variables could be moved into the meta data

-- MartinCleaver - 05 Nov 2001

Another feature that would be useful: immediate notification once to the last editor: When saving a topic you could check boxes to:

  • Mail the next time this topic is edited (and only the next time)
  • Mail me immediately when this topic is edited (every time in the future)
I think both features are useful

-- ColasNahaboo - 05 Nov 2001

A few comments. It is possible to edit meta information using the undocumented 'cmd' feature - however, this is a last resort feature!

I think we can do more with forms, but a present they lack a field type that could be used for multiple person selection e.g. for notify. Note that if this approach was taken, each WebForm for a Web that had per-topic notify, would need to include the field for notify. The same is true for allow Set to work via forms.

Meta data does add complexity to the original Wiki idea. But, I do think it is cleaner than the hidden html that was previously used for forms and attachments.

-- JohnTalintyre - 06 Nov 2001

I think that using forms for meta data edit would not be a normal end-user feature; normally plug-ins to would be responsible for each piece of meta data.

I don't understand: "Note that if this approach was taken, each WebForm for a Web that had per-topic notify, would need to include the field for notify." - can you clarify?

-- MartinCleaver - 06 Nov 2001

I don't see why meta data would have to be the responsibility of plugins - can you give some specific examples? As for using forms for per-topic notify: A Web can have several different forms. Each form would need to include the per-topic-notify field, or the forms mechanism would have to be changed to involve some form of inheritance, a complexity too far I would think.

-- JohnTalintyre - 06 Nov 2001

Sorry, I didn't mean that all meta data would be the responsibility of plugins, I meant that certain plugins could provide a nice interface for setting / displaying meta data. For instance the per-topic notify plugin could ensure that the list of topics notified could be restricted to people, as listed in the Main web. Furthermore it could add 'add me'/'remove me' buttons that manipulate the list by assuming the current user.

As for using forms, I meant that a form could be used as a generic meta data editor.

If I correctly recall, isn't part of the meta data namespace reserved for plugins? If so, the plugin can store the subscription list in there.

-- MartinCleaver - 08 Nov 2001

I've created a ImmediateNotifyPlugin that can do something akin to this. At the moment it sends notifications via the Jabber instant messaging protocol, but it's designed so that an e-mail backend is only a short step away. The way it's currently documented, it only works on a per-Web bases, but it also has a (currently) undocumented feature that allows you to include a line of the form:

      * Set IMMEDIATENOTIFY = WikiNameOne WikiNameTwo WikiNameThree
in a topic and have those names be notified when that topic is updated.

-- WalterMundt - 04 Feb 2003

I've added SMTP support to Walter's ImmediateNotifyPlugin as well as support for groups.

-- JuergenPabel - 25 Mar 2003

Please read ConsolidateNotification and MailerContrib

Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r21 - 2004-12-28 - MartinCleaver
  • 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.