ScriptRunner Dynamic Forms > how to use in method?

[Petr Papousek]

Hi @Adaptavist Supp,

On ScriptRunner 6.5.0-p5 & JIRA 8.5.8, I'm trying to utilize Dynamic forms feature

when used in simple script (which is then in fact compiled into class anyway), it works as expected.

However if I try to use in a class like this (file ParClass.groovy):

package experiment

import com.onresolve.jira.groovy.user.FieldBehaviours
import com.onresolve.scriptrunner.parameters.annotation.ShortTextInput

class ParClass extends FieldBehaviours {
    def run() {
        @ShortTextInput(label = "Summary", description = "Enter a short issue summary")
        String asdf

        return asdf
    }
}

I get the following error:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: file:/.../scripts/experiment/ParamClass.groovy: 8: Script parameter annotations are only allowed at the top level of scripts and inside of instance methods @ line 8, column 9. @ShortTextInput(label = "Summary", description = "Enter a short issue summary") ^ 1 error

Am I doing something wrong, or is this approach not supported (yet)? Error says "and inside of instance methods", but I wasn't able to get it running in a method

Best regards,
Petr

[Helmy Ibrahim _Adaptavist_ · Accepted solution]

Hi @Petr Papousek 

Technically Groovy compiler transforms each script (a file that has code at the top level rather than a class declaration) into a class which has groovy.lang.Script as an ancestor. But declaring a class which extends groovy.lang.Script has slightly different semantics - an example difference would be that you can further extend such class whereas you cannot extend a "pure script".

Dynamic forms have been designed around being used in "pure scripts" because they employ AST transformations to extract the metadata about parameters as described by the annotations used and also inject their values at runtime as configured using the rendered form. If dynamic form annotations were allowed in classes extending groovy.lang.Script then you could theoretically use them in a superclass (e.g. consider this inheritance structure groovy.lang.Script -> com.example.BaseScriptUsingDynamicForms -> com.example.ScriptConfiguredInTheForm) and if that superclass was provided on the classpath in the form of a class file (compiled file) then we would not be able extract metadata about form parameters used in that script because we need to compile the sources to be able do that. So while you are right that a "pure script" is transformed into a class extending groovy.lang.Script there are valid reasons why usage of dynamic form annotations is not supported in classes explicitly extending groovy.lang.Script.

Anyway, there is a workaround if you really need to be able to use dynamic forms with classes extending groovy.lang.Script. Simply declare your script class as the @BaseScript in a "pure script" and pass any dynamic form parameters to a method on that class. So the class would look like this:

import groovy.util.logging.Log4j

@Log4j
abstract class DynamicFormParmetersProcessingScript extends Script {
    void processParameter(String parameterValue) {
        log.warn("Parameter value: ${parameterValue}")
    }
}

And the script like this:

import com.onresolve.scriptrunner.parameters.annotation.ShortTextInput
import groovy.transform.BaseScript

@BaseScript DynamicFormParmetersProcessingScript baseScript

@ShortTextInput(label = "Summary", description = "Enter a short issue summary")
String formField

processParameter(formField)

Hopefully that helps.

[Petr Papousek]

Hi @Helmy Ibrahim _Adaptavist_ , thanks a lot for your explanation.
It's not that I would be so obsessed with using the class + dynamic for parameter combo. :-)

Context is, that I'm maintaining a larger REST endpoint, which I prefer to have defined as class, so the code could be appropriately separated to number of methods and called from e.g. from tests conveniently.
I had two separate files - class and "pure script" defining a rest endpoint, instantiating and calling the class, but I was struggling with the class file not being recompiled when it's code changed, so I was trying to keep it as one file, so the recompilation need is properly detected.

anyway, it's quite a while, so I can give it another try, maybe it will work ok now :)

[Tim Eddelbuettel]

Hi @Petr Papousek,

did you ever find a solution for the issue?

Regards,
Tim