Motivation
In any site, there are topics are changed frequently but that don't merit change notifications. Among the distributed topics with this property
are WebStatistics and WebNotify. WebNotify is a particularly notable (and annoying case); it is usually edited manually, but despite the instructions a normal save is often done.
Sites may have similar topics - a common example is sign-up sheets for an activity. Rarely do the participants care to know that others have signed-up (though the sponsor/organizer will monitor the topic.)
Unless users are knowledgeable and careful enough to setup their subscriptions to ignore such topics (and few users are), SPAM results.
Besides clogging inboxes, it desensitizes users to change notices.
Description and Documentation
Add a topic preference (in theory it could be set at a web level) that causes the
minor option to default to
true when saving a topic.
This will effectively prevent all notifications for topics with the preference set.
Set that preference on the WebNotify template and other topics with the same property.
How the preference is spelled doesn't matter; I suggest
ALLSAVESAREQUIET.
Examples
Impact
Implementation
The easiest place to do this is in Store::saveTopic, where
minor can be defaulted to
true if the preference is set.
Store should be coded such that
minor == 0 does
not result in a quiet save. This allows for automation to
explicitly request notification for a change, and for future overrides by the UI.
Although it could also be done in the UI, this is more involved and I don't think it's necessary.
--
Contributors:
Timothe Litt - 2014-02-05
Discussion
The intent of this proposal is to suggest the minimal change necessary to solve the long-standing manual edit to
WebNotify and similar topics. Expanding the scope makes implementation unlikely.
Some might suggest that topics with
ALLSAVESAREQUIET should have a
Noisy save button replace the
Quiet save button
when editing a topic. I don't think this is necessary for the intended use cases, but it could be a future enhancement.
Including it would increase the scope of the change.
One could imagine more elaborate schemes, such as using the preference to update WebNotify and/or WatchList to exclude such topics
in order that truly interested parties could still receive notifications. While such schemes have some utility, they're of larger scope and
again could be future enhancements.
--
Timothe Litt - 2014-02-05
You can do that already with the DONTNOTIFYCHECKBOX setting defined in
TWikiPreferences on the page level, or if you want on a whole web. It is just an on/off switch, not the list you propose. That is, you could add this setting to
WebNotify and all other topics that you do not want editors to notify other people. Does that fit your needs?
Since the
MailerContrib is marked as deprecated in TWiki-6.0 we should design and enhance the
WatchlistPlugin.
--
Peter Thoeny - 2014-02-05
I don't need a list. On/Off would be fine. I mentioned the more complicate 'future enhancement' possibilities to only to ensure that implementation doesn't preclude them.
I'll have to figure out why DONTNOTIFYCHECKBOX doesn't show up even in my svn HEAD wiki's TWikiPreferences topic - even after svn up'ing core/data/TWiki. I see it here, and I do remember the checkbox.
However, try editing this topic. No checkbox. Raw or
WYSIWYG. The checkbox disappeared at some point and was replaced with the "Save" and "Quiet Save" buttons. It's not present in HEAD, or in my 4.2.3 (+!TopMenuSkin) system.
For fun, I added Set DONTNOTIFYCHECKBOX = checked="checked" to this topic and made a trivial edit. I was still notified by Watchlist (which wouldn't have happened if the
minor option was set).
So the DONTNOTIFYCHECKBOX feature doesn't exist, at least with current skin.
If you want to turn this into a bug report against DONTNOTIFYCHECKBOX, that's OK with me.
I agree that WatchlistPlugin should be the future. Although the WebNotify topic was used as an example, the requirement is not dependent on MailerContrib. Both notification methods look at the
minor flag.
There currently is no way to default this on a per-topic (or per-web) basis.
As an aside, WatchlistPlugin can't replace MailerContrib until (at least):
- There is equivalent capability in WatchList expressions
- Item7411
has a prototype for "watch all" and "watch new", not accepted
- Still missing negative specifiers (e.g. * -Web*)
- There is a script to migrate WebNotify topics to WatchList topics
- (Probably) There is an equivalent to the 'news mode' capability
- (Probably) there is more selectivity about frequency - currently digest v.s. immediate is per-user; probably needs user to be able to specify by topic and/or web.
Doing all that without complicating the simple UI of WatchlistPlugin will require a lot of engineering. Deprecating MailerContrib was premature.
--
Timothe Litt - 2014-02-06
At the
KampalaReleaseMeeting2014x02x06 we decided to handle this as a bug,
TWikibug:Item7430
:
- Replace "Quiet save" button with previously used checkbox
--
Peter Thoeny - 2014-02-08