You may want to migrate behaviours from one Jira instance to another. Currently, there is no automated way of migrating behaviours, but there are some REST APIs that help with migrating the configuration.

Below we explain the process of migrating Behaviours using the REST API, take care when following these instructions.

  1. Enter this URL into your browser address bar to provide the mapping between behaviours and projects/issue types:

    <JiraBaseURL>/rest/scriptrunner/behaviours/latest/config
    CODE
    <Behaviours>
        <project pid="10001" configuration="1"/>
        <project pid="10003">
            <issuetype id="10004" configuration="2"/>
            <issuetype id="10000" configuration="2"/>
        </project>
    </Behaviours>
    CODE

    Each configuration ID above (1,2) is a single behaviour.

  2. Paste the following URL into your browser address bar to return the configuration of a behaviour, where 2 is the ID of one of the behaviours above:

    <JiraBaseURL>/rest/scriptrunner/behaviours/latest/config/2
    CODE

    The configuration of behaviour 2 is shown:

    <config use-validator-plugin="false" validate-jira-requiredness="false" name="test">
        <field id="customfield_10011" readonly="true"/>
        <field
            id="customfield_10013" validator-method="" validator-class="" validator="server"
            validator-script=" getFieldByName("TextFieldB").setFormValue("Hello World") "/>
        <field id="customfield_10014" required="true"/>
    </config>
    CODE

    As you can see, custom fields are identified by their ID (for example, customfield_10011). If you are migrating this to another system, check the XML and manually update any custom field IDs that don’t match the new system. If you are editing a behaviour, make changes directly to this XML in a text editor.

    If your development environment is a copy of your production environment, or you are just editing a behaviour, the IDs should match and do not need changing.

    Project and issue types are also represented by IDs and might need updating before migration.

  3. Once the XML is updated, post it to your production instance, using:

    curl  -X POST -u admin:admin --header "X-Atlassian-Token:no-check" --header "Content-Type:application/xml" -d @b1.xml <jira-base-url>/rest/scriptrunner/behaviours/latest/config/1

    Where b1.xml is the contents of the behaviour configuration, and admin:admin is an admin username and password.

    If a behaviour already exists with this ID, the command above overwrites it.

  4. Once you have recreated any behaviours, you can write the mappings to the production server:

    curl  -X POST -u admin:admin --header "X-Atlassian-Token:no-check" --header "Content-Type:application/xml" -d @bh.xml <jira-base-url>/rest/scriptrunner/behaviours/latest/config

    Where bh.xml contains the mappings retrieved in Step 1.

    This overwrites any mappings already defined. Make sure you test the procedure on a non-production instance first.

    Please check the documentation for curl for the system you are on. We are not able to support you in this procedure.