Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Jira ScriptRunner scripted field shows $xmlutils.escapeForCdata($value.toString()) in Confluence

Kamran Ansari August 26, 2020

Environment:

  • Jira Data Center v8.8.1
  • Confluence v7.4.0
  • Adaptavist ScriptRunner for JIRA v6.4.0-p5

Problem:

We're using the canned scripted field Date of First Transition that ScriptRunner comes with. The field shows up correctly in Jira (UI, filter results, etc.) and the data comes through the JIRA REST API just fine.

However, when the scripted field is included in the Confluence macro Jira Issue/Filter, it shows up as $xmlutils.escapeForCdata($value.toString()) instead of a date/time value.

Steps to reproduce:

  1. Create a ScriptRunner scripted field of type Date of First Transition for any issue status. Configure it and make sure its working correctly in Jira.
  2. Create a filter in Jira (example: bugs submitted by a certain user)
  3. Create a Confluence page, and insert the macro Jira Issue/Filter in the page. Configure the macro to use the filter from step 2. Set the display options to "Display as: Table", "Maximum issues: 20", and make sure to include the scripted field from step 1 as one of the columns to display along with other standard fields.
  4. Click "Insert" to insert the macro into the page.
  5. Save the page.
  6. When the page renders, all data shows up correctly, except the scripted field which renders as  $xmlutils.escapeForCdata($value.toString())

 

Please help, as this has become a major blocker for our reports.

Thanks,

Kamran Ansari

2 answers

Suggest an answer

Log in or Sign up to answer
0 votes
Вячеслав Рыжов December 1, 2020

Having same issue :(

@Kamran Ansari - have you found how to fix it?

Thank you

Kamran Ansari December 1, 2020

@Viacheslav Unfortunately, no.

I wish Adaptavist customer support was as good as their product, but unfortunately, this issue failed to get any traction from them. In the end, I had to implement a workaround which involved creating a string version of this scripted field using a Groovy script. So basically, we have two versions of the same field now:

1. Using Date of First Transition that is "JQL Date Time functions" friendly but NOT Confluence friendly

2. Using a custom scripted field that is Confluence friendly, but won't work with JQL.

Unfortunately, I won't be able to share the Groovy script with you, but you should be able to find plenty of examples online on how to walk the Jira issue change history to get to the bit of information that your Groovy script needs to return. The key is, you need to return the date/time string.

Hope that helps. If you do come across a better solution, I'd appreciate if you could post about it here, so others in the same boat could benefit.

Good luck!

Вячеслав Рыжов December 2, 2020

Ok. Thank you for answer.

In my case - i have a field wich show version start date for issue

Template - date

here is a code

import org.slf4j.Logger
import org.slf4j.LoggerFactory
import java.sql.Timestamp
import com.atlassian.jira.project.version.Version

Logger log = LoggerFactory.getLogger("Release Version")
log.info("Release Version started")

Version version = issue.getFixVersions()[0]
log.debug("Version: ${version}")
Timestamp result = (version)? version.getReleaseDate() : null
log.debug("Resuilt: ${result}")
log.info("Release Version ended")
return result

 

But in Confluence it shows 

 $xmlutils.escapeForCdata($value.toString())

 

So i create second field special for confluence jira issue macros

Template - text field

import org.slf4j.Logger
import org.slf4j.LoggerFactory
import java.sql.Timestamp
import com.atlassian.jira.project.version.Version

Logger log = LoggerFactory.getLogger("Release Version")
log.info("Release Version started")

Version version = issue.getFixVersions()[0]
log.debug("Version: ${version}")
String result = (version)? version.getReleaseDate() : null
log.debug("Resuilt: ${result}")
log.info("Release Version ended")

 

def format1 = result
def format2 = Date.parse("yyyy-MM-dd hh:mm:ss", format1).format("dd.MM.yyyy")

return format2

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 2, 2020

For what it's worth, it's not a problem with Scriptrunner, it's the way Jira serves up field data to Confluence.  That's why you got no traction with SR support - there's nothing they can do to fix it.

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 26, 2020

I think you might have to fix this by changing the output of the scripted field.

I think you have selected a type of field which has formatting that relies on Jira's UI code to be rendered usefully for the users hitting the web interface, but Confluence does not know that this data needs to be rendered, it displays the physical data being returned.

So, you would either need to get Confluence to understand that it needs to do some rendering, or you have to simplify the output so that it does not need to be rendered and can be drawn out raw.

Kamran Ansari August 26, 2020

Hello Nic,

Thanks for the quick turnaround on this!

To your point about fixing this by changing the output of the scripted field and simplfying it:

I don't know if that's possible, given that I'm using one of ScriptRunner's canned field called Date of First Transition, and I haven't been able to find a way to change its output via the field configuration dialog (the only way to interact with this field). All it lets me do is specify a Field Name, Field Description, Field Note, Issue Status, and Preview Issue Key. The Groovy code that the field is bound to is to be found nowhere.

More importantly though, the return data-type of the field is Date/time which both ScriptRunner and Confluence should be well equipped to handle, and I feel that changing it to a simpler type (such as string) would come with other undesirable effects (JQL date/time functions and comparison operators would probably no longer work, for example).

Thoughts?

Thanks!

TAGS
AUG Leaders

Atlassian Community Events