[PATCH] suppress ticket notification when only status changed

[Patrick Schaaf]

Similar to the ignore_cc_change option, this enhancement can be used to suppress notification mail when nothing but the status of a ticket changes.

In some parts of our trac workflows, there are sequences of three or four workflow steps, expressed as successive status values, and half of the time these steps are passed without comments or other changes being made. That is not a problem in itself, but it is annoying to often receive three or four notification mails in short succession consisting of nothing but these status changes.

With this patch applied, I can suppress these notifications.

New options for trac.ini in the [announcer] section are

Option	Type	Default
ignore_status_only	bool	false
no_ignore_status	list	empty

The patch feature is only activated when ignore_status_only = true is set.

If you have certain status values, e.g. started and review, for which you still want notifications to be sent regardless of ignore_status_only = true, you can write no_ignore_status = started, review.

Patch is against the 0.11/ version of the announcer plugin, because that is what I have installed + can test right now.

[Patrick Schaaf]

ignore_status_only option

[Ryan J Ollos]

I've been meaning to do something similar, suppressing notification in any case that there is no comment. That way, if only the status, milestone, component, etc... are changed, no notification is sent.

[anonymous]

I think that the suppression conditions useful in concrete trac deployments, will vary widely with the practises of the deployment.

Meaning that this way of adding suppression conditions is not good. This calls for one or more extension point interfaces. I have not thought this through, but here are some thoughts on that:

• one extension point would be responsible for testing (potential) conditions for suppression
• it might be desirable to have, for each such condition, both a project wide activation default, and a user preference override, and maybe a "locked" setting for the project wide default
• thus, in the producer(s), the condition extension point test would be run, but first its result would only be recorded in the event
• and then the distributor(s) would match conditions against system and user preference, and act accordingly.

Does that sound like a plan? Any other ideas / thoughts?

[Patrick Schaaf]

Implemented such a framework in #9048 along with various other things.

The functionality of the patch here, is contained in that other ticket.