Tags:
create new tag
view all tags

Bug: Using once the "Minor changes, don't notify" box can prevent further notifications

Test case

  1. Edit a topic and save without notification
  2. the mailnotify script runs
  3. re-edit and save normally within one hour of [1]
No notification is emitted.

Environment

TWiki version: Feb 2003
TWiki plugins:  
Server OS:  
Web server:  
Perl version:  
Client OS:  
Web Browser:  

-- ColasNahaboo - 03 Apr 2003

Fix record

In lib/TWiki/Store.pm, line 595, the assumption is false!

        # fix topic by replacing last revision, but do not update .changes
Since we must update changes even in this case.

Patch provided, that factorize the code in if( ! $dontNotify ) { in a new procedure writeChanges that is called at both places: the old one and the "replace revison" case.

-- ColasNahaboo - 03 Apr 2003

Follow up

Colas, thanks for the patch. An issue needs to be addressed before it goes into the core.

There are actually two reasons for not notifying more then once:

  1. If a user edit a page 2 minutes before the regular notification is sent, and then edits the same topic again 5 minutes later, a second notfication is sent out for the same edit session.
  2. The changes file does not get "spammed" with many changes to the same topic. This can be an issue because only the last 100 entries are kept in the file, which could push out the latest not yet notified entry.

I am not sure how problem 1 could be solved with your patch. Problem 2 can be solved by removing older entries of the topic each time a topic is saved (need to worry about longer processing time? The open - update - save time should be as short as possible).

-- PeterThoeny - 06 Apr 2003

Yup. But in my case, the [1] behavior may be desirable (users rely on notification not to miss any change to their important topic. Even more so with the various mods to get notified on only one topic). They prefer to get more mail rather than missing notification. If this bothers them, they would have removed themselves from the notification altogether, in my experience. For instance, users told me "email notification do not work" to signal me this bug.

On 2, why not just append all changes to "changes", with no size limit and let the mailnotify script do the cleaning?

PS: Email notification enhancement become quite important for my company. Do you work / have some planned design for this? I will certainly code something this week, but I wanted to know if you already had ideas...

-- ColasNahaboo - 07 Apr 2003

On 1: Good argument, double notification is better then a missed notification, so lets go for your solution.

On 2: Good idea of just appending, this is even faster with a ">>" then the current read - update - save sequence. No issue if the cleanup in mailnotify takes a little longer. Small detail, we need to keep the last 50 unique topic changes, this is because the changes script is still part of the distribution, although it is more or less replaced by the WebChanges topic with an FormattedSearch.

I currently have very long hours at work and cannot spend enough time on TWiki development. If you help out, great smile

-- PeterThoeny - 08 Apr 2003

Updated patch for Cairo: SaveWithinHourShouldNotifyChangeV2.patch: For Cairo

-- ColasNahaboo - 04 Jan 2005

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch SaveWithinHourShouldNotifyChange.patch r1 manage 3.1 K 2003-04-03 - 23:48 UnknownUser to lib/TWiki/Store.pm, Feb 2003 version
Unknown file formatpatch SaveWithinHourShouldNotifyChangeV2.patch r1 manage 3.2 K 2005-01-04 - 16:55 UnknownUser For Cairo
Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2005-01-04 - ColasNahaboo
 
  • 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-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.