Opened 12 years ago

Closed 12 years ago

#9031 closed enhancement (duplicate)

[PATCH] suppress ticket notification when only status changed

Reported by: Patrick Schaaf Owned by: Robert Corsaro
Priority: normal Component: AnnouncerPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11


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


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.

Attachments (1)

announcerplugin-ticket-ignore_status_only.patch (1.5 KB) - added by Patrick Schaaf 12 years ago.
ignore_status_only option

Download all attachments as: .zip

Change History (4)

Changed 12 years ago by Patrick Schaaf

ignore_status_only option

comment:1 Changed 12 years ago by 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.

comment:2 Changed 12 years ago by 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?

comment:3 Changed 12 years ago by Patrick Schaaf

Resolution: duplicate
Status: newclosed

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

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

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Robert Corsaro.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.