Opened 5 years ago

Closed 5 years ago

#9031 closed enhancement (duplicate)

[PATCH] suppress ticket notification when only status changed

Reported by: bof Owned by: doki_pen
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 bof 5 years ago.
ignore_status_only option

Download all attachments as: .zip

Change History (4)

Changed 5 years ago by bof

ignore_status_only option

comment:1 Changed 5 years ago by rjollos

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 5 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 5 years ago by bof

  • Resolution set to duplicate
  • Status changed from new to closed

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

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

Add Comment

Modify Ticket

as closed The owner will remain doki_pen.
The resolution will be deleted. Next status will be 'reopened'.

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

Note: See TracTickets for help on using tickets.