#6516 closed enhancement (wontfix)
[PATCH] Including content of ticket fields in outgoing notification email headers
Reported by: | qwp0 | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | notification | Version: | |
Severity: | normal | Keywords: | ghop consider review patch |
Cc: | doug.hellmann@…, androsis@…, Thijs Triemstra | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I (as 'androsis') have claimed a ticket in GHOP ( http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=255 ) — "Update trac to include more ticket fields in outgoing email headers". There have been already posted some patchs, so it maybe useful for you to have a ticket here too.
I attach my most recent patch for this task (it can be found on the GHOP ticket of this issue too)…
P.S.: I have not found any existing ticket where I could post this, so if there is already a ticket about that I'm very sorry.
Attachments (2)
Change History (21)
by , 17 years ago
Attachment: | trac-notification-headers_v3(tests).diff added |
---|
comment:1 by , 17 years ago
Cc: | added |
---|
comment:2 by , 17 years ago
Summary: | Including content of ticket fields in outgoing notification email headers → [PATCH] Including content of ticket fields in outgoing notification email headers |
---|
comment:3 by , 17 years ago
Type: | defect → enhancement |
---|
comment:4 by , 17 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:5 by , 17 years ago
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
comment:6 by , 17 years ago
Keywords: | consider added |
---|---|
Milestone: | → 0.12 |
comment:7 by , 16 years ago
Cc: | added |
---|
comment:8 by , 16 years ago
Closed #1359 as duplicate of this one.
We could eventually have something like a smtp_x_trac_ticket_headers
option with the possible values of ALL, CHANGED or a list of fields.
comment:9 by , 16 years ago
Hi, I created a patch which works with the configuration option mentioned by Christian, created against the trunk repository, exactly r7639. I don't know if it's ideal because this ticket should be done for milestone:0.13.
Unfortunaly, because of the too extensive unit testing I can't upload it here, sorry — the file is available at http://tests.php5.sk/tmp/trac-notification-x_trac_ticket_headers.diff
I know it's none of my business now for the GHOP task (see the ticket description) is not actual but I hope the patch will be useful.
by , 16 years ago
Attachment: | trac-notification-x_trac_ticket_headers.diff added |
---|
copy of qwp0's patch linked in comment:9
comment:11 by , 14 years ago
Keywords: | patch added |
---|
comment:12 by , 13 years ago
Hi, is there any chance of getting this patch merged soon, to be able to make its way to 0.13?
follow-up: 14 comment:13 by , 12 years ago
Can you restrict the number of header fields that are included on the annnouncer email, based on the ticket type ?
comment:14 by , 12 years ago
Replying to phooper0001@…:
Can you restrict the number of header fields that are included on the annnouncer email, based on the ticket type ?
From the patch:
"Possible values: ALL, CHANGED or comma-separated list of ticket properties"
But not depending on the ticket type. That should be relatively trivial to add (e.g. another config options whose name includes the ticket type).
Back to the original patch: it looks fine and useful, comes with tests et al… Only lacks a "champion". I've been away from the notification code for too long and we just don't dare to touch it much these days given all the existing known issues and the recurring plans for replacement. But still, if someone would like to have a try at reviving the patch, he would be welcome.
comment:15 by , 12 years ago
I don't quite see the need for the proposed smtp_x_trac_ticket_headers
option.
Unless this option is set to the value "CHANGED", it doesn't seem like it would address the use case in #1359 — setting up a mail filter for tickets whose owner was just changed to myself. If the option is set to "CHANGED" then this use case will be supported, but it means that there needs to be cooperation between the end-user's mail filters and the trac administrators who are configuring the system. And if I'm participating in several Trac environments, I can't confidently set up the same mail filters for all of the environments.
Meanwhile, I don't really see the advantage of having the option. Why would an administrator choose to suppress any headers?
It seems like this is better off being non-configurable: always send a separate mail header for the current value of every field, and a separate value for the old value of every field. That way setting up mail filters to detect changes, or current values whether or not they've changed, would be easy and consistent.
comment:16 by , 9 years ago
Owner: | removed |
---|---|
Status: | reopened → new |
comment:17 by , 8 years ago
Could now be implemented as a plugin? Untested:
from trac.config import ListOption from trac.core import Component, implements from trac.notification.api import IEmailDecorator from trac.notification.mail import set_header class TicketFieldEmailDecorator(Component): implements(IEmailDecorator) smtp_x_trac_ticket_headers = ListOption('notification', 'smtp_x_trac_ticket_headers', 'CHANGED', doc="""Possible values: ''ALL'', ''CHANGED'' or comma-separated list of ticket properties. Those properties are put into the e-mail headers when notifying about ticket updates.""") # IEmailDecorator methods def decorate_message(self, event, message, charset): if event.realm != 'ticket' or event.category == 'batchmodify': return def header(value, *parts): name = '-'.join(part.capitalize() for part in parts) set_header(message, name, value, charset) fields = list(self.smtp_x_trac_ticket_headers) prefix = 'X-Trac-Ticket' if fields == ['CHANGED']: for item, change in event.changes['fields'].iteritems(): for type, value in change.iteritems(): header(value, prefix, item, type) elif fields == ['ALL']: for item in event.target.values: header(event.target.values[item], prefix, item) else: for item in fields: header(event.target.values[item], prefix, item)
comment:18 by , 8 years ago
Milestone: | next-major-releases |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
comment:19 by , 8 years ago
I tested the recipe and confirm that it works as described.
X-trac-ticket-Milestone: milestone4
Duplicate of #1359