Script overrides JIRA Issue type scheme

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.

2 answers

1 accepted

1 vote

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.

 

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.

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,

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.

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

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.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Jul 10, 2018 in Marketplace Apps

If you’re an Atlassian app developer, you’ll want to know about Atlas Camp!

This September 6-7, hundreds of Atlassian App developers will flock to Barcelona Spain to build skills, discover product roadmaps, meet face-to-face with the Atlassian team, and learn how to extend t...

179 views 0 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you