Add ticket change email headers to allow more intelligent filtering of ticket notification emails

[chris@…]

Basically, Trac sends (if configured properly) emails to the users each time a ticket is modified. In my case, I wanted to filter the tickets a bit, to identify tikets being closed or assigned to me.

Unfortunately, if your mail goes to an IMAP server without server filters, most email clients can't filter on the contents of the body, where the specific field changes are enumerated. Plus that would be, well, ugly.

This change adds additional X-Trac email headers each time a ticket is changed.

These headers are of the format:

X-Trac-Ticket-Change-<field>

with the new value of the field as the header value.

This allows for easy client side filtering, nd handles the case when multiple changes are made in one submission (you get multiple headers in the email, 1 per field)

Thanks for watching!

[chris@…]

Patch against the trunk to add additional email headers for ticket notifications

[cboos]

Consider for 0.12.

[eblot]

I'm wondering if is worth overloading the SMTP headers with potentially many fields.

Couldn't a single header, X-Trac-Ticket-Changes: with a comma separated list of modified fields as value be enough?

[chris@…]

A list *might* be enough, but I used this change extensively to do really intelligent filtering on a project where I got hundreds of notifications a day. It was far easier to setup filters for specific headers; parsing (especially with server side filtering agents like Sieve) might be much harder. Besides, aren't headers pretty well understood?

[eblot]

See also #6516 which contains another patch

[cboos]

For filtering, doesn't #6516 makes more sense?

Proposing to close this one as duplicate of #6516 (superseded by, actually).

[chris@…]

The original urge for writing this patch the way it is is exactly as cited above: "I used this change extensively to do really intelligent filtering on a project where I got hundreds of notifications a day. It was far easier to setup filters for specific headers; parsing (especially with server side filtering agents like Sieve) might be much harder."

Having lots of headers made it easy for vanilla filtering tools (like Sieve engines) to filter in some really complex ways; if it was a list it would have been far more tedious.

[cboos]

chris, in case you had some doubts, I was not saying that the meaning of the "text" of comment:9 was spam, rather than a spammer had the good idea to copy the text from (your) comment:6 as a whole before adding a spam link at the end of it, in order to circumvent the spam protection system...

[cboos]

See superseder #6516.