I am currently switching my issue type from a story to a bug when the issue is created from a specific initiator. How can I change my automation so that if the issue is switched by another initiator it stays to what the other initiator switched it to.
Example - Jira story created by user X so the Jira automation changes it from a story to a bug. Another user Z looks at the issue and identifies it as an actual story instead of a bug, so they switch it to a story. User X then makes a comment, and my automation then switches it back to a bug. I want to prevent the switch back once user Z has made the issue type change.
Hi @Pfohl Jason
First thing, and in my opinion, it is generally a bad idea to change the issue type with an automation rule. There are many things to check when changing type, and this is why Jira has a specific feature for this: Move. Automation rules cannot make those checks (or show a dialog) to handle any problems.
Back to your question...
The key issue is the trigger. For your scenario, the issue type should only change after the Issue Created trigger. That will eliminate any back-and-forth for future changes to the issue.
And to prevent some users from using Move to change the type back again, please review this article: https://confluence.atlassian.com/jirakb/prevent-users-from-editing-the-issue-type-from-an-issue-1206790073.html
Kind regards,
Bill
Hi @Pfohl Jason , thanks for your question.
Please can you explain what you are trying to achieve with this rule?
I have understood that only certain people should be able to update certain fields. I would suggest you could do this with something like a workflow transition screen, using conditions and / or validators so that only people with the correct permission can make changes to specific fields in an issue.
Please can you take a look at this documentation and give your feedback about whether these could help with your case?
https://support.atlassian.com/jira-cloud-administration/docs/configure-advanced-issue-workflows/
Cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the response @Valerie Knapp My organization has the workflow settings where I am not able to change them. This is why I was trying to automate what I need done.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Pfohl Jason , thanks for the clarification. I would still involve the admins for the instance in what you are trying to do. I understand what you are saying about the workflows but in approaching the admins with your use case, they might prefer to modify the workflow rather than use automation as, depending on your tier / plan, automation can have limits which also need to be monitored and considered.
Good luck!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Pfohl Jason
Can I clarify the logic here...
...is this correct?
And, you can't change the Workflow or the Permissions, correct?
Ste
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.