Script overrides JIRA Issue type scheme

[Georges Moubarak]

Hi,

I have added a postfunction script using script runner that created linked issues to the current issue.

It reads the project names of the linked issues from a custom field and sets the same issue type for all of them.

We have recently added a project where its issuetype type scheme doesn't contain the same issue type as the script. When we ran the script, it has created a new issue of the newly added project with the same issue type as in the script knowing that this project doesn't contain this issue in its issue type scheme.

How was Script Runner able to overrule JIRA's schemes.

[Nic Brough -Adaptavist- · Accepted solution]

It doesn't do it in itself.  What the script runner does is allow you direct access to JIRA's API, so you can run code within JIRA as though you'd written an add-on, or even part of the core code.

That means you can do whatever you want with the API, including ignoring all the rules that are implemented elsewhere.

This is one reason why we always recommend that Script Runner usage is limited to people who understand the API, or at least (like me) understand it well enough to know when not to do things.

Your new issue type is going to cause you problems, you do need to swap to another type, or add the new one to the other project.

[JamieA]

Exactly. And note that although you can use Issue.setIssueType to set an issue type, it will not be consistent (unless you do it before the issue is created). You could argue that this is a bug in the JIRA API.

[Georges Moubarak]

Hi @Jamie Echlin [Adaptavist], I raise it originally as a JIRA bug but they wanted to hear your feedback about it. Thank you for your support,

[JamieA]

Np. Just to qualify one thing Nic said. "Script Runner usage is limited to people who understand the API". That's true if you doing stuff in production, which is why you should make sure you have dev and staging instances. ScriptRunner is ideal for *learning* the API, you just don't want to be making mistakes in production.

[Nic Brough -Adaptavist-]

Yes, sorry, test systems are fair game for learning scripts.

[Chris Solgat]

There is one other piece to this that is likely a culprit as well.  That would be the simple fact that you are using the same workflow that contains the Scripted Post-Function in the new project.  I would imagine within your project schemes (issuetype, workflow, screens, fields, etc...) there is a default option in addition to any of the specifics you laid out.  One of the reasons for these default options is so that when something like this scenario happens, JIRA doesn't completely freak out.  The simplest answer would be to make sure that the new project is using it's own workflow and that it doesn't contain the Scripted Post-Function.  If for whatever reason you decide to continue using the same workflow, then you would need to modify the post-function script to verify that it is in the correct project and using the correct issue-type before it creates the new issue/sub-task.