Help with accessing data passed in formToken via webwork.action.ActionContext ?

[Bryan Karsh]

Hi gang,

I could use some advice. I have a script that will create a ticket as part of a post-function. It works great except for one bit: the transition has some additional fields to fill out -- and that information is supposed to be passed to the new ticket.

I notice that when I try to copy the values from the original ticket, the information is stale. So I am assuming I need to use something to look at the httprequest itself? So I was looking at examples from webwork.action.ActionContext -- I see posts online about how to leverage this library to verify or add links to other issues as part of a transition -- or require attachments be added during a transition. But what I am having difficulty finding is how to parse the request ... or I guess more specifically the formToken. I can see that the formToken will have information like this:

formToken=[Ljava.lang.String;@2873b4d, customfield_14201=[Ljava.lang.String;@7cd9853, customfield_14202=[Ljava.lang.String;@6f57345d, commentProperty=[Ljava.lang.String;@292fe461, comment=[Ljava.lang.String;@1249ef5a}

.. but how do I get the values stored in customfield_14201 and  14202?

Anyway -- any tips would be much appreciated. If anyone is curious why I am not using the handy ScriptRunner built-in that does this, it's because I am working on a script that can be called from any project transition that calls it. I plan to have the script live on the application server. It's part of some updates we are making to Incident management, that depending on what you enter in the transition screen, it will spin up and link issues as appropriate.

Thanks again!

[Ivan Tovbin · Accepted solution]

Hi,

Could you please clarify:

1) How exactly this script is supposed to be used? Is it a listener, a post function?

2) If this is a listner, wouldn't it be better to have it trigger on a custom event, which will be thrown by your transitions? That way you can grab all the necessary field values directly from the issue.

[Bryan Karsh]

Hi Ivan,

That.... is ... brilliant. I was initially thinking listeners, but discounted this approach because I was assuming it would be listening to everything, and would therefore add undesirable load to our already over-taxed instance. But by using a custom event, I would be able to control the load to only when the custom event itself was fired yes? I will play with this approach, and let you know how it turns out.

[Bryan Karsh]

This solution worked perfectly. Thanks Ivan! :)