Script Runner create issue from WebUI Fragment

[Jordan Berry]

Here is what I am trying to do:

Have a button live on an issue page, where the user can click it.

When clicked, I want that button to create another issue, inheriting some of the current issues field values.

In an ideal world, I would also like to be able to prompt a screen to get some user information, but that isn't a direct requirement right now

Is this something I can achieve with ScriptRunner? If so, how do I start getting the UI element to start calling a script?

It is working going through post functions, but I am trying to break this away from workflows, as they are getting messy.

[Peter-Dave Sheehan]

Hi @Jordan Berry 

While this can all be done with scriptrunner, this is getting into add-on territory in terms of complexity.

I know you said you have it working via workflows, but just in case your implementation is different or others come across this post, this is what I'd recommend:

• For the "button" add a workflow transition (from any status to the same status).
• Then for prompting for information, you use custom jira fields in a transition screen.
• Only the final piece requires scriptrunner but in a much more limited way and potentially without any scripting. In the post function, you can use the built-in script function "clone issue and link".

But I can see the appeal of separating this from the workflow so that it can be enabled across multiple projects/workflows with one central design.

If you really want to get in the business of using web fragments and custom dialog, then I'd recommend you start with a simple example as described here and prepare yourself for a fairly long learning journey. You may wish to consult this area as you build your dialog.

I've done this myself with just about the full range of capabilities that Scriptrunner offers

• DB resources to read/store values in a custom db
• REST API to serve the UI element and data and receive POSTs from the form
• Scripted JQL to enable functions to search for data stored in my db for this custom tool
• Web Item fragments to have the button on the issues to start with
• Web Item resources to host all the javascript used by the dialog
• It generates events and sends custom emails

Here is what that dialog looks like:

This has dropdown and popups and user preferences and type-ahead select2 drop-downs. We use it in conjunction with our subversion pre-commit hooks to control if commits using a certain Jira ticket should be allowed or not. Devs must request approval before attempting to commit and Release Managers must approve those requests. This is only during the release period while we're in code freeze mode.

So can it be done? Sure. 

Should you? That depends on you. I certainly enjoyed my learning and I'm proud of what I achieved.

Sorry, this post ran away from me :/

I hope some tidbit in here helps.

[Jordan Berry]

Hey Peter,

Thank you for the breakdown! I was doing some more digging and I think using the create issue web fragment with behaviours may be the way I go, but I really like the approach and cleanliness of what you have shown.

Right now we have it all working with Postfunctions, but they are making the workflows convoluted, and they are causing a lot of slowdown in the project/jira instance. Trying to take as much away from that workflow as possible at the moment

[Peter-Dave Sheehan]

Yeah, a post function that creates many clones can take a while.

If the slowdown is not an actual server resource issue, one thing you can try, but requires creating the clone via custom script instead of built-in options, is to use the Threa.start construct: 

Thread.start{ 
   //code to create your issues
}

This will start the threads to create the issues asynchronously so that the postfunction will terminate immediately and the user won't have to wait for the issues to be created before the app is available for subsequent changes.