ScriptRunner script fields custom templates behave differently by context?

[Joshua DeClerck]

When using a custom velocity template to render a script field, the behavior when 'previewing' it appears to have significant/breaking differences from how the template behaves on actual issue screens. Particularly around the type of the $value... value.

For example, if my script field returns a map object, I can tell a custom template to render a value from that map. In other words, if I tell the template to render...

$value.get('some_key')

The referenced value pops out successfully. Woo.

If I then go to look on at the field on the same tested issue key directly after saving this setup, the field cheerfully shows a literal "$value.get('some_key')".

Poking at it a bunch, it seems to be because, in "real" Jira, $value is always, alllllways just a string, so there's nothing to 'get' and velocity does its fallback behavior.

So I guess I have two questions?

1. Is ScriptRunner's preview function bugged/incorrectly handling values and overpromising, just to break my heart later, and
2. Is there any way to pass more than a single just-a-string to the template? Can additional parameters go between the script and the template in some way?

[muschol]

Having run into the same problem, I worked out what the answer is: it is all about choosing the right Search Template for your custom field.

The Searcher determines what the value will be cast to (e.g. String, Number, Duration) before it is passed into the custom velocity template.

So just go to Settings->Issues->Custom Fields, find your field, hit Edit and choose "None" as the Search Template for your custom field. I have found that when I do that, it allows me to pass objects of different types into the velocity template and they are not just converted to strings.

[Rakesh Kumar]

Hi Joshua,

To test this, i just used a simple script and i don't see the expected output in preview as well. I observed that it showed correct value in preview for first 2-3 executions only.

def testMap = new HashMap<String, String>()

testMap.put("test", "Value")

return testMap

In custom template, 

$value.get('test')

Please let me also know if you get any solution for this.

Regards,

Rakesh

[Nic Brough -Adaptavist-]

So, I'd love to answer this one, but I'm not certain enough of what I'd like to say to do it.  My instincts are

1. Not a direct bug, but a feature of how Jira's plugin system interacts with SR and Velocity, which is clumsy in places.  Maybe a bug that happens because none of the three elements thought about that one particular case in any detail.  And, yes, I think SR probably is over-promising in this case.
2. There should be, variables should be generally available, but I've never tried to write a script that uses more than one, so I really do not know.

I don't often do this on Community, but I think this one is really worth asking the experts about.  Could you raise a support request with the SR team over at https://productsupport.adaptavist.com/servicedesk/customer/user/login?destination=portals

If you do get a good answer from my colleagues, please share!

[Joshua DeClerck]

I'll definitely get a ticket going there and see how things turn out (and share!). In the time since I posted, I got a temporary workaround for just this one use case by using string methods to grab the values out of the former map. Hopefully there's a better way out there.

Regarding (2), there's an impression that the $value returned by the groovy script is the only input we have control over. This does feel like an advanced area for users with some experience extending Jira outside ScriptRunner that would help with understanding it all, so yeah, I might just be totally unaware of something available to me.

But for cute little custom field ideas like "I want this to look like a lozenge with a variable tooltip in Jira but export as/allow JQL filtering on just the word", this is probably where I should be looking. I do wish the documentation included some examples to learn from -- this is now in my bucket with Confluence scripted macros as something I could spend way too much time not getting very far on. =)