Changes between Version 19 and Version 20 of WorkflowNotificationPlugin
- Timestamp:
- Feb 3, 2016, 7:22:09 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WorkflowNotificationPlugin
v19 v20 9 9 Administrators can configure any number of distinct email notifications to be sent out when a workflow operation occurs on a ticket. Each email notification is specifically attached to one or more workflow operations, so (for example) separate emails can be sent out when a ticket is accepted, reassigned, resolved, reopened, or marked "in QA". 10 10 11 Each email notification's subject, body, and recipients are fully configurable by administrators, as Genshi templates which have access 12 to the ticket's data, the comment (if any) that was left on the ticket, and the author of the change. Therefore notifications can be very flexible: some notifications can be sent to the ticket's reporter, others to its owner or CC list, others to the current updater, and others to hard-coded lists of users. 11 Each email notification's subject, body, and recipients are fully configurable by administrators, as Genshi templates which have access to the ticket's data, the comment (if any) that was left on the ticket, and the author of the change. Therefore notifications can be very flexible: some notifications can be sent to the ticket's reporter, others to its owner or CC list, others to the current updater, and others to hard-coded lists of users. 13 12 14 13 The notification emails sent by this plugin respect Trac's `ALWAYS_CC` and `ALWAYS_BCC` settings. 15 14 16 The notification emails sent by this plugin are orthogonal toTrac's `ALWAYS_NOTIFY_UPDATER`, `ALWAYS_NOTIFY_OWNER` and `ALWAYS_NOTIFY_REPORTER`15 The notification emails sent by this plugin are independent of Trac's `ALWAYS_NOTIFY_UPDATER`, `ALWAYS_NOTIFY_OWNER` and `ALWAYS_NOTIFY_REPORTER` 17 16 settings. Trac's built-in email notifications will be sent according to those settings, independent of this plugin's emails. 18 17 … … 54 53 }}} 55 54 56 Now you just need to configure some notifications ;see below for details and examples.55 Now you just need to configure some notifications, see below for details and examples. 57 56 58 57 == Example … … 62 61 Configure one or more notification emails attached to workflow events using a `ticket-workflow-notifications` section in `trac.ini`. 63 62 64 Within this section, each entry is a notification email that may be sent out for a ticket. 63 Within this section, each entry is a notification email that may be sent out for a ticket. Here is an example: 65 64 {{{#!ini 66 65 [ticket-workflow-notifications] … … 80 79 Multiple independent notifications can be configured for the same workflow action; in the above examples, both the `notify_owner_changed` and the `notify_reported_when_accepted` rules will be triggered when the "accept" action occurs. 81 80 82 The following lines define the email subject, body, and recipients for a particular notification. These are all Genshi Text Templates that 83 will be rendered with a context that includes the ticket (in its current state AFTER the workflow action has been applied); the author 84 and comment of the current change, if any; a link to the ticket as `${link}`; and the project. 81 The following lines define the email subject, body, and recipients for a particular notification. These are all Genshi Text Templates that will be rendered with a context that includes the ticket (in its current state AFTER the workflow action has been applied); the author and comment of the current change, if any; a link to the ticket as `${link}`; and the project. 85 82 86 83 All of these must be defined for each notification; the plugin will raise errors at runtime if a notification is missing any of the `.subject`, `.body` or `.recipients` definitions. 87 84 88 The `.recipients` definition should be a Genshi template that renders to a comma separated list of email addresses and/or usernames known to Trac. 85 The `.recipients` definition should be a Genshi template that renders to a comma separated list of email addresses and/or usernames known to Trac. In the above example we combine a dynamic variable based on the ticket's current state, a username known to Trac, and a hard coded email address: 89 86 {{{#!ini 90 87 notify_reporter_when_accepted.recipients = ${ticket.reporter}, trac-admin@hostname.com, trac_user 91 88 }}} 92 89 93 === Conditional Notifications90 === Conditional notifications 94 91 95 In addition to the required configuration fields described above, you can optionally include a `.condition` definition for a notification. If provided, this should be a Genshi text template which evaluates to the value True if and only if the notification should be sent. If the template evaluates to any value other than True, the notification will be skipped. 92 In addition to the required configuration fields described above, you can optionally include a `.condition` definition for a notification. If provided, this should be a Genshi text template which evaluates to the value True if and only if the notification should be sent. If the template evaluates to any value other than True, the notification will be skipped. 96 93 97 94 If the notification should be sent unconditionally when it is triggered, the .condition line should be set to `${True}`. … … 102 99 [ticket-workflow-notifications] 103 100 when_fixed = resolve 104 when_fixed.body = Ticket ${ticket.id} has been fixed! 101 when_fixed.body = Ticket ${ticket.id} has been fixed! View it here: ${link} 105 102 when_fixed.subject = Ticket ${ticket.id} is fixed! 106 103 when_fixed.recipients = ${ticket.cc} … … 152 149 === Notifications when no action has occurred 153 150 154 A workflow action always occurs when a ticket is changed, even if the user doesn't explicitly select a workflow action! In the standard Trac configuration, the default action is "leave".So you could set up a notification like so:151 A workflow action always occurs when a ticket is changed, even if the user doesn't explicitly select a workflow action! In the standard Trac configuration, the default action is "leave". So you could set up a notification like so: 155 152 156 153 {{{#!ini … … 163 160 === Accessing old ticket values 164 161 165 The ticket's old values are available in the notification templates. These values are provided in a Python dict named `old_values`. The 166 values provided are from before any changes were made to the ticket, whether by workflow operations or by direct user action. 162 The ticket's old values are available in the notification templates. These values are provided in a Python dict named `old_values`. The values provided are from before any changes were made to the ticket, whether by workflow operations or by direct user action. 167 163 168 164 You can use this dictionary to set up a notification similar to Trac's built in ticket change email, for example: … … 175 171 }}} 176 172 177 === Using Blank Lines in the Announcement Emails173 === Using blank lines in the announcement emails 178 174 179 175 As the examples above show, you can add blank lines by typing "\n" in your email template. The plugin's code will parse these "\n" strings into actual newline characters. So, for example, this configuration should result in an email body with four blank lines between the two sentences:
