Converting Groovy Scripts

Converting Groovy Scripts

This is the path from a verified conversion in a Migration Analysis to a script running on your Cloud site. A converted Data Center script is a draft until a human has read it — nothing in this flow runs anything for you.

Migrate one script

  1. Open the script in the analysis Read What this script does, why it was classified as it was, and each finding. Change the feature type on the row if the classification is wrong — the type sets what the script can become.

    Migration script detail with summary, classification and findings

    Script detail with findings and verdict

  2. Check the conversion A Verified conversion has been compiled and its SDK calls checked against the real endpoint index. Read What changed and every caveat. A conversion that did not verify shows why, and cannot be migrated until it does.

    Verified conversion of a Groovy script showing what changed

    Verified conversion with what changed

  3. Migrate to Scriptbox Choose a name under Save as. The script is saved to the Console tab as version 1, and its description records the source file, the analysis and how many caveats it carried. Any parts of the original that did not come across are listed before you confirm.

    Migrate to Scriptbox dialog with save name, caveats and a disabled listener option

    Migrate to Scriptbox dialog with caveats

  4. Optionally create its trigger, switched off

    • Listener → Also create a listener, disabled, with suggested events from the script's own branching. A raw file does not carry the events its listener was bound to, so check them.
    • Scheduled job → Also create a scheduled job, disabled, with a cron expression and timezone. A Data Center job's Quartz schedule does not come across in the file — set it here.
    • Scripted field → Also create a scripted field, switched off, with a name and type. The field type cannot be changed later.
    • Post function → add the Scriptbox: Run a script rule to the transition in Jira's workflow editor afterwards.
    • Behaviour → create the behaviour on the Behaviours tab afterwards, with its projects, issue types, views and affected fields.

  5. Read it, then run it yourself Open the script on the Console tab, read it end to end, and run it. Write-capable conversions follow the APPLY = false pattern — confirm what it reports before switching writes on. Then enable its listener, job or field.

What changes between Groovy and Scriptbox

On Data Center In Scriptbox
event.issue in a listener context.input.issue
ComponentAccessor, managers, in-process Java No equivalent — the conversion uses Jira Cloud REST through jira.sdk
@WithPlugin and other apps' APIs No equivalent — Scriptbox reaches Jira only
ScriptRunner JQL functions (issueFunction) No equivalent — precompute into a field with a scheduled script
Quartz schedules (0 0 2 * * ?) 5-field cron in a chosen timezone (0 2 * * *)
A scripted field computed per issue A script that answers for a batch of issues
Groovy validators and conditions Jira expressions, or a script validator
"Run as" a named user Run as: Me in the console; the app for every automatic trigger
Outbound HTTP to other systems Not available — no egress

When a script cannot come across

For REST endpoints, fragments and JQL functions, the script detail explains what would be needed and offers to use the assistant to work through this configuration. The Scriptbox Assistant will say plainly which parts cannot be ported and propose the nearest thing Cloud supports — it will not invent an endpoint to paper over a gap.