Tickets: No way to skip notifications to subscribers for certain (minor) modifications

[Ryan J Ollos]

Consider the following scenarios for editing a ticket:

1. Changing a minor typo in the ticket Description
2. Adding some entries to the Keywords field
3. Changing the Milestone, Component, Type, etc.
4. Adding an attachment, when the attachment was mentioned in the previous message, so that users expect it will be posted to the ticket within minutes and don't need to see another email telling them that it was added.

Users on my team receive a lot of email from Trac each day, and it is frustrating and Trac becomes less effective when they receive email notifications when someone is just cleaning up or making some minor changes to a ticket.

Rather than setting up a lot of options in trac.ini that determine who and when a subscriber is notified of changes, I propose that a checkbox is added to the right of Submit changes. When the Don't Notify Subscribers checkbox is selected, the ticket update should not send notification emails.

The question then arises: what permission should be required for this checkbox to be present. Perhaps someone running a Trac instance does not want users to be able to change a ticket without, for instance, the ticket's owner receiving a notification. I propose two options for the [notification] section of trac.ini:

1. optional_notify_authenticated = {true, false}
2. optional_notify_anonymous = {true, false}

Option 1 would show/hide the Don't Notify Subscribers checkbox for authenticated users. Option 2 would show/hide the Don't Notify Subscribers checkbox for anonymous users. Users with TICKET_ADMIN permission would always see the checkbox.

[Ryan Ollos <ryano@…>]

Request-A-Hack on Track-Hacks.org: ​#5495.

[jevans]

Alternatively perhaps add TICKET_CLEANUP and WIKI_CLEANUP permissions (or some such) to control access to the option. Personally I'd only allow it for minor text edits - I'd want notification of property changes. But yes, there have been times I haven't made minor corrections to avoid sending notification. Sounds like a great hack.

[Christian Boos]

Sounds interesting, and in line with the discussion in #7758.

But if I may, we are more in need of an active maintainer for the notification subsystem than yet another tweak ;-)

[Christian Boos]

#5332 was closed as a duplicate of this ticket.

[bebugz@…]

For these impatient like me wouldn't that be a quick-n-dirty solution to make custom boolean field on ticket (trac.ini) and hardcode/patch the notification to analyse of this field to completely off the notification. As the proposal prior to proper longterm solution.

[anonymous]

​th:QuietPlugin is what I've been using to satisfy this need.

[fbrettschneider@…]

See also #10574 that also addresses the problem of ticket statistics comment overhead, and suggests to split into 2 ticket comment types where only the usercomment-releated stuff is posted as notification.

[Peter Suter]

#10405 was closed as a duplicate.

[Peter Suter]

#11535 was closed as a partial duplicate / wontfix.

Integrating QuietPlugin functionality was suggested, or even a subscriber that allows configuring rules like Never Notify: Updater was in quiet mode in the notification user preferences.

[Ryan J Ollos]

#12067 was closed as a duplicate, requesting the ability to disable notifications from batch ticket modification.

[Philippe Cloutier <chealer@…>]

Thank you for reporting

I agree with the issue, but not that much with solutions.

I basically agree with jevans that authorization should be controlled via permissions. As for which fields can be modified, this overlaps with ticket #6217.

Regarding the checkbox, that could work for me, but is not ideal. Wikimedia projects have constant issues with the "Minor edit" checkbox. Although MediaWiki defines somewhat objective criteria for when it should (not) be used, there are mistakes, even from administrators. Contributors just don't know these and often cannot refrain from escaping their colleagues’ supervision.

Labeling the checkbox with regards to its effect (Don't Notify Subscribers) avoids the difficult question of defining minority, but then limits what can be done with the value. In MediaWiki page histories, minor edits are represented differently.

Which brings to another question: is this issue really specific to tickets? In my opinion, the same at least applies to wiki pages too.

Instead of a checkbox, there could be an input field offering to rate the modification’s importance (on a scale of 0 to 5). This would let each subscriber define is own threshold, keeping it possible to subscribe to all changes.

Regarding the specific scenario of attachments, there are at least 2 alternatives:

1. Solving the equivalent of issue #3204 for ticket modifications
2. Adding a delay before sending notifications (which helps not only with this issue, since we all know how often we realize a mistake/omission rather after submitting…)

This comment is from Philippe "Chealer" Cloutier. I am subscribing to this ticket, but notifications seem to be broken, and I struggle to display my full email address or link to my contact information from this comment. My email address is available on Kune ni povos’s contact page. All of my comments and contributions in this ticket are offered under the terms of CC0 1.0 (unless otherwise noted).