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.
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.
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.
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.
Hi Atlassian Community! This is Teresa from the Jira Service Desk team. On June 19th, I’ll be hosting a webinar “Asset Management: The Role of Context in ITSM” with Atlassian Partne...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events