Could you call a method (with input parameters) from one scripted field in another scripted field?

[Geoff Wilson]

Question Goal: To have one script that contains a bunch of helper and query methods, each with various parameter input needs, that can be used to specific data (depending on the input need) and being able to call these methods from within some other script.  Currently, the script is being stored in a Scriptrunner custom Script field because we don't know where else to put it. Also, we don't know if there's any way to pass in input to a custom script field or if it's possible to call a method in this scripted field from within another scripted field, so that we can avoid copying the same 200 lines script over and over again to new custom fields. In testing scripted fields, you can pass in an Issue Key through the GUI. 

Ultimate Goal: Using Xporter, to be able to export various data values found within, referenced by, or linked to one or more issues.

Example: For a particular Fix Version on a project, automatically query for all Tasks/Defects/etc issues of that version, total up the number of issues returned, and export that total value to one cell in an Excel spreadsheet. Additionally and more complex, also grab a custom field SLOC value from each of these query-resulting issues, total all of those custom field values up, and also exporting that value to a single cell within the Excel spreadsheet.

[adammarkham · Accepted solution]

It sounds like you want some utility methods available across different scripts.

For this you need to place your utility class in the script roots. See the example in the docs here: https://scriptrunner.adaptavist.com/latest/jira/#_script_roots

Hope this helps.

[Geoff Wilson]

Will look into this and try it out.  Thanks

[Geoff Wilson]

ACTUALLY, maybe what I'm looking for just lies with whether or not we can create our own Scriptrunner functions and how?  That way we could write a function with a script behind it that we can call and pass in parameters to it?

[Geoff Wilson]

Yes, we could copy this class script over and over and put the entire thing into 1+ custom fields that each have their own specific hardcoded purpose like one to return the total of this and one to return the total of that. But instead, it'd be more efficient to have a main header script of sorts that we can plug in whatever new value we desire and have the method class script that holds all of the logic.

ex:

• (maybe we want the custom field SLOC Delta value from each Defect issue that is found from a query on which issues have the same fixVersion of our currently selected issue)
• getResultFromScript("fixVersion", "Media Date")
  • This then ideally would call a different script / scripted field we wrote with all methods and such inside it that can then take the fixVersion and Media Date parameters we specified and return a result
• now we can use this same getResultFromScript(input) script to query on a totally different subset of data with only one custom field rather than copying the fully body of the methods script into multiple custom script fields to do only the hardcoded query returns (e.g. one custom field that returns results from hardcoded fixVersion and Media Date, another custom field that returns results from hardcoded affectVersion and Previous Version, etc etc)

[Steven F Behnke]

I'm not to sure yet, can you clarify why you believe this all can't fit inside of a single ScriptRunner Script Field?