Page Comparison

...

A Preview Context contains webhook event data for a previously processed event. This context allows previews of notification Templates at edit time. In this example, we'll add custom content for the resolution of an issue. By default there are only Created, Updated and Deleted event templates, so this will be a modification to the Updated event template.

1. Convert a received webhooks from JEMHC > Auditing > Events, into a Preview Context that can be used with Template Sets.

2. Create Custom Macro to provide detection logic and rendering of required content

Creating Preview Contexts

...

An event entry will look something like this:

...

Press (…) > View Event Data to show the webhook Webhook data:

...

Clicking the + Create Preview Context icon converts that data into a Preview Context:

...

Simplified, the webhook structure can be seen below. Full details on the webhook data structure can be found in this Atlassian documentation.

 {
    "timestamp",
    "webhookEvent",
    "issue_event_type_name",
    "user": {
        //--> See User shape in thelinked linkeddocumentation
document    },
    "issue": {
      //  --> See Issue shape in thelinked linkeddocumentation
document    },
    "changelog" : {
     // See Changelog shape in the linked document
   },
   "comment" : {
     // See Comment --> See Changelog shape in inlinked the linkeddocumentation
document    }
 }

The $context reference used in all templates represents this webhook data structure. It important to know that it is a reference to an object of type ObjectNode.

...

The values in all nodes like $context.issue.id result in the value shown in the webhook data. For example "40301".  The quotes normally need removing, and this can be done with $context.issue.id.asText().

All ‘asText()’ values are effectively a java String object, so all related methods can then be used, eg .toLowerCase()

Most properties lie under the $context.issue.fields prefix, as shown:

#foreach ($item in $context.issue.fields.customfield_13600)
  $item.value.asText()
#end

<h1>Prior Comments</h1>
<p>Issue $context.issue.key.asText() has $fields.comment.total comments</p>
#foreach( $comment in $fields.comment.comments )
<h3>Comment created $comment.created.asText()</h3>
$jemhUtils.wikiToHtml($comment.body.asText())
#end

<h2>STATIC comment extract</h2>
<pre>
1) $fields.comment.comments[0].id -- $fields.comment.comments[0].created -- <p>$fields.comment.comments[0].body.asText()</p>
2) $fields.comment.comments[1].id -- $fields.comment.comments[1].created -- <p>$fields.comment.comments[1].body.asText()</p>
3) $fields.comment.comments[2].id -- $fields.comment.comments[2].created -- <p>$fields.comment.comments[2].body.asText()</p>
</pre>

<h2>REVERSED comments</h2>
#if ($fields.comment.total >0)
#foreach($i in [1..$fields.comment.total])
#set ($actualIdx = $fields.comment.total - $i)
#set ($comment = $fields.comment.comments[$actualIdx.intValue()])
<p>
<h3>Comment created $comment.created.asText()</h3>
$jemhUtils.wikiToHtml($comment.body.asText())
</p>
#end
#else
no comments yet
#end

Working with dates

#set( $createdStr = $comment.created.asText() )
#set( $timeStr = $createdStr.substring($createdStr.indexOf('T')+1) )
#set( $timeSplit = $timeStr.split(":"))
<h3>Comment created date: $createdStr.substring(0,$createdStr.indexOf('T')) at $timeSplit[0]:$timeSplit[1] </h3>

#set ($dateObj = $dateFormatter.getDate($comment.created.asText()))
$dateFormatter.format($dateObj, "dd/MMM/yy h:mm a")

Create a custom macro

The System Macros show macros defined within JEMHC and inherited by all instances:

...

Here is a hello world “hello world” macro , which takes two parameters, accessed through $param1 and $param2 which can then be used inside the macro body.

You can define references inside macros that are then available afterwards to the caller.  This is useful for flagging specific situations, which is what we will do with the issue resolved status.

#macro ( helloworld $param1 $param2)
<B>Hello $param1 -- $param2 </B>
#end

The Custom Macros are   are user editable, the following text contains the render method that will be called from our template, as well as the workflow transition detector 'helper' method.

...

This means that the preview icon Image Removedicon (Eye Icon) will dynamically do the rendering and show the result, demonstrating (a) The changelog data contained an issue status change matching what was expected, and (b) The content was rendered via macro invocation:

...

Using the text preview again, we get to see what the rendered output showing the custom output for issue resolution looks like.

...

To further be sure this is doing the right thingtest the template, change the Preview Context to be an event that is not an issue resolution. Doing so will automatically re-render the content, and you'll find it isn't on the Resolved screen any more.

With the Preview Context and Template rendering features you can validate correct behaviour up front, saving time!

Example templates

Identifying recent attachments

...

Adding all attachments from an issue to a template could be problematic if a large quantity of attachments where are present on an issue. The following script can be used to identify if attachments where were recently added to the issue.

...

Filter by label (Content by label)
showLabels false max 5 spaces JEMHC showSpace false sort modified showSpacetype falsepage reverse true typelabels pagetemplate webhook velocity cql label in ( "velocity" , "template" , "webhook" ) and type = "page" and space = "JEMHC" labels template webhook velocity

Page Properties
hidden true
Related issues

...