Tags:
create new tag
view all tags

Feature Proposals » Add a topic preference for quiet saves

Summary

Current State: Developer: Reason: Date: Concerns By: Bug Tracking: Proposed For:
RejectedProposal   RejectedByReleaseMeeting 2014-02-05      

Edit Form

TopicSummary:
CurrentState:
CommittedDeveloper:
ReasonForDecision:
DateOfCommitment:   Format: YYYY-MM-DD
ConcernRaisedBy:
BugTracking:
OutstandingIssues:
RelatedTopics:
InterestedParties:
ProposedFor:
TWikiContributors:
 

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

WhatDoesItAffect: Documentation, Prefs, Usability

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

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2014-02-08 - PeterThoeny
 
  • 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.