Option to *selectively* not send email notifications on ticket change

[Jared Bownds]

http://trac-hacks.org/ticket/5495

I'd like to visit this feature request.  I admit I do not have an initiate understanding of the ticketing system, but from the surface it seems quite trivial to simply mute emails - this behavior could even be hidden from users without the appropriate permissions.  In terms of desired behavior, add a button called "Silent Submit" next to the "Submit Changes" button that would mute any form of notification from being sent.  Instead of considering a full blown plugin, perhaps there is a hacky way to do it until AnnouncerPlugin is integrated?

[Ethan Jucovy]

On Wed, Aug 6, 2014 at 1:25 PM, Jared Bownds <jared....@gmail.com> wrote:

http://trac-hacks.org/ticket/5495

I'd like to visit this feature request.  I admit I do not have an initiate understanding of the ticketing system, but from the surface it seems quite trivial to simply mute emails - this behavior could even be hidden from users without the appropriate permissions.  In terms of desired behavior, add a button called "Silent Submit" next to the "Submit Changes" button that would mute any form of notification from being sent.  Instead of considering a full blown plugin, perhaps there is a hacky way to do it until AnnouncerPlugin is integrated?

The Workflow Notification Plugin (http://trac-hacks.org/wiki/WorkflowNotificationPlugin) can address this -- you'd just need to swap out the default notification system and replace it with this plugin's version for all notifications to make it work properly.  Once that's done, though, there are several ways you could configure this behavior using the plugin.

-Ethan

[Jared Bownds]

Hi Ethan,

Thanks for contributing to the conversation.  Are you suggesting the following workflow configuration (see [ticket]) to achieve the desired result?  I could use some suggestions on how to emulate the existing behavior offered by Trac, eg. continuing to utilize ticket_email_plaintext.txt for specific email conditions

In summary, If you were to implement this feature for yourself — how would you address it from a workflow configuration standpoint — in the context of replacing Trac's default notification workflow?

[ticket]
workflow = TicketWorkflowNotifier

--
You received this message because you are subscribed to a topic in the Google Groups "Trac Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/trac-users/N72FBxcd8js/unsubscribe.
To unsubscribe from this group and all its topics, send an email to trac-users+...@googlegroups.com.
To post to this group, send email to trac-...@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.

--

Jared Bownds

c. 916-224-2324

e. Jared.Bownds@gmail.com

[Jared Bownds]

Here is an example of the direction I'm headed.


[ticket]
workflow = TicketWorkflowNotifier



[ticket-custom]

silence_email = checkbox
silence_email.label = Silence Email
silence_email.options =
silence_email.order = 7
silence_email.value = 0

[Jared Bownds]

On second thought, approaching the desired behavior by way of a ticket property is not going to work.  This method would be permanently attached to the ticket, and would not provide a flexible enough platform for a workflow notification condition.

[Chris Shelton]

I have recently starting using the QuietPlugin (http://trac-hacks.org/wiki/QuietPlugin) on my trac installation for situations where I want to temporarily disable the email notifications.  The only notable caveat is the requirement to be using the AnnouncerPlugin for notifications, but since I was using that already, the QuietPlugin was a nice option to have for temporarily disabling notification messages.

chris

[Ethan Jucovy]

On Wed, Aug 6, 2014 at 6:59 PM, Jared Bownds <jared....@gmail.com> wrote:

On second thought, approaching the desired behavior by way of a ticket property is not going to work.  This method would be permanently attached to the ticket, and would not provide a flexible enough platform for a workflow notification condition.

Using a ticket property is one way, but you're right that it's a bit weird since its state would persist on the ticket.  If you're willing to fiddle around with other plugins or write a one-off plugin you could probably force the checkbox to reset its state after each submission, though.

Or, you could also add custom workflow action(s) which the WorkflowNotificationPlugin is configured not to respond to -- e.g. a "leave_quietly" action in addition to "leave."  This only really works if your quiet ticket changes all involve leaving the ticket's state -- if you need quiet versions of assign, reopen, resolve, etc., as well, then you'll end up having to mirror your entire workflow configuration which is probably too messy to be worthwhile.

And lastly, you could set up a conditional notification that looks for the presence or absence of some keyword -- e.g. `notification.condition = ${"@quiet" not in change.comment}` -- and instruct users to include that keyword in their ticket change comments if they want notifications suppressed.

I hadn't known about QuietPlugin though -- it seems like that might be a simpler solution.

 

-Ethan

You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+...@googlegroups.com.