Support setting up notifications for a JSD scenario


I'm currently replacing JSD's notifications with a setup using JETI. It's harder than expected, so I thought it would be useful to list some issues here:


I've created templates based on the default JIRA templates, but now need to update those so that they link to the portal view of the issue instead of the JIRA view, because customers cannot access the JIRA view.

To get this done I added a script field (using Script Runner) that returns the portal URL of an issue. JSD still doesn't have an api so there's no easy way to get it. I query the db.

In my JETI templates I can then insert that custom field. However, If you use jetiFieldRenderer.renderCustomField then it automatically adds html tags around the URL and you get for example:

To simply get the URL you have to use jetiFieldRenderer.renderCustomFieldAsObject, but this isn't documented.


For some reason when a customer creates an issue in a portal, JETI does not pick up the create event. The JIRA notification scheme does. JSD picks it up as well.
As a workaround I added a postfunction to the workflow that sends the correct email using JETI when a issue is created.

Support engineers can update a number of fields that are not interesting/visible to customers. Because we have the "Issue Updated" event in our Notification Template, this will trigger emails that contain those fields (because the JIRA template shows them). We can update the template to only include the fields that we want to expose, but this means that customers will still receive emails for those changes, even though the email will not appear to contain any changes.

Some things that would help
  • Provide a helper method to insert a link to the portal view of an issue in an email template

  • Document the helper methods that are available in templates

  • It would be nice if JETI already included defaults for the JSD templates instead of having to start from the JIRA templates

  • Support ignoring updates to a list of fields. Or the other way around: only send notifications for updates to a given list of fields. Or alternatively, only send notifications for fields that are configured for the portal and request type.

  • Is the missing Create notification a JETI bug?

  • Support debug logging to figure out why a notifcation was sent, or was not sent for specific cases, so that it becomes easier to figure out if you have a problem with your context/notifications/template, ... configuration



Preliminary Test Cases



Tibor Hegyi


Glenn Verrijkt



Access to limited visibility issues


Product platform


Module Dependency


Fix versions

Affects versions