You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
See if you can help me find this gap that I can't identify.
I have this automation with the function:
Clone a change and the trigger is through a field...That is there is a button where users click on clone, when they clone they fill the value of the field to YES, but right after that there is an action in the automation that should return that value to NO, because they may want to clone more than 1 time the same change.
In all statuses the rule works fine, but when trying to clone in closed status it gives this error.
I know it is something permissions related, the rule author is Automation for Jira himself and in the workflow properties it is already with edit permission. I leave the evidence here for more details.
In the Workflow Status Properties for the Closed status I see that you allow 3 user groups and 1 project role to edit issues in that status.
Is the "Automation for Jira" user a member of any of the specified groups? I expect not.
What Project Role has the ID 10002? If that is not the "atlassian-addons-project-access", then add another entry for that same property with the ID for that Role.
Hi @Kelly Arrey
Yes, there is no such property in the workflow in closed status.
What I did was put some groups that have permission to edit in this status, more common user should not have this access, what properties do I have to put to get?
I share the image as it is today, because it seems to me that the automation author is without permission, but shouldn't the automation for jira already be understood as admin?
@Karoline Rezende Ramos I think you're getting the error because this Edit issue field needs to be dragged beneath the "Add comment" block so it is within the "For All created issues".
The error you're getting is because the Automation is trying to update scope_change on a closed issue. Normally closed issues cannot be edited.
Hi @Darryl Lee,
Per my understanding, @Karoline Rezende Ramos is trying to do the same thing as expected in the automation rule.
If I am not wrong, the flow of changes is:
I assume the 'scope_change' is already part of the 'Edit' screen as otherwise the user will not be able to update this field in the first place.
I have checked that it is possible to update the closed tickets in most cases unless the property is set otherwise.
I am trying recreate the scenario and test.
First thanks for the comments.
This is exactly what happens.
1. The person uses a button, provided in the clone issue.
2. When he uses this button, I added a post function to change this field to YES (Trigger of the rule)
3. Automation creates the cloned issue and links it to the original ticket.
4. The action in automation edit: You would have to change the value of the "scope_change" field to NO (where it is showing the mentioned error)
Because if it is set to YES people can't clone this issue anymore. I don't know if it was clearer.
Don't mind me asking this.
If you are allowing the users to clone the same issue multiple times, is it not better to just clone the issues directly without checking for whether the 'scope_change' value is changed to 'YES' and trying to change it back to 'NO'?
Hi @Vamsi Kandala
We have some different conditions and needs, this rule allows to clone a change management, there are people who open weekly, monthly and the body of the change is the same, so we provide this feature, and the trigger we use following the best practices is by changing a field.
In our instance we already have some automations, and we are avoiding using the same trigger, because we already had an incident of delay in execution and according to Atlassian's support we should do it this way.
I have observed that error when the custom field is not on the edit view, the custom field is different type/value (such as for team-managed or multi-project rules), the rule actor does not have permissions for edit, and when the issues have been made read-only.
Would you please post an image showing the audit log details when the rule works as expected for an issue clone? That may eliminate some of the possibilities.
Are you showing the entire rule in the screen image?
I ask this question because the log details showing the failure show that the Edit Issue Fields action is after the if/else conditions and inside the same level. So that edit could not be the one which is failing.
There must be another Edit Issue Fields later in the rule which is failing.