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
Next: Root
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
I am trying to set up a simple Jira Automation rule and no matter what I do, I cannot maintain the original reporter for the issue.
The trigger is set to fire when the Team for an issue in our main project (PF) is edited. Based on which Team is chosen, that issue needs to be Cloned into the corresponding Team's project (for example, PF1) so that we can keep the original field values and attachments.
However, it is vitally important we know who the original Reporter (i.e., creator) is, so teams can make sure to loop that person into essential development conversations. As of now, I have tried so many (literally countless) variations of smart values and ways to set up the rule that I've found on these forums (a handful which appear to work for others, even) but none of which work for me. I can't possibly list them all out, so just please trust me.
As of now, the "Automation For Jira" user has all necessary permissions to edit the reporter in any of our projects (PF, PF1, PF2, etc.) and I do as well. No matter who the actor is, I can't change the reporter. The field configurations across projects are exactly the same, and as such, Reporter is available across all of our projects. All users in our system are also available to be chosen a Reporter in PF or PF1.
I get this particular error most often, no matter how I set up the rule: "Unknown fields set during clone, they may be unavailable for the project/type. Check your custom field configuration. Fields ignored -Reporter (reporter)". It is extremely vague, and as I've mentioned, I've checked permissions and field configurations numerous times and do not see any issue. I've tried various smart value syntaxes that I've seen but have no way to corroborate what is the right one, since other users on these forums have had success with different styles of writing and/or using the smart values, but none work for me in this case.
Does *anyone* have any idea why this isn't working or the actual correct way in June of 2021 to make it such that the cloned issue can maintain the original reporter? I'm thinking of throwing the display name in the Description text field, but that's less than ideal. I'm at my wits end with this, so any help at all would be appreciated tremendously.
When I tried that in an automation rule, copying the Reporter from the trigger issue, it worked for me. I have noted posts for that error message/symptom when either the target field was not on showing the page view configuration or a duplicate custom field of the same name had been created.
Would you please post an image of your rule and the audit log? That may give the community some context to try to offer suggestions. Thanks!
Best regards,
Bill
Hi @Bill Sheboy,
I appreciate your willingness to help, but I'm concerned if I show the rule as it is now, after I've tried tons of different ways to do this, that it will just cause me to go through all the same steps I've already done. I'm really trying to avoid running over the same ground because I simply do not have the time to retrace steps. Would you instead be willing to show me how your successful rule is set up to get the Reporter from the trigger issue, so I can affirm whether or not I've tried that method already? I think that would save me a great deal of time, if you wouldn't mind doing so. Would be happy to go through some of the scenarios that did not work for folks in the community after that.
Also, I can confirm that the target field "Reporter" is showing on the page view configuration for both projects (they are essentially identical projects in their configuration). I can also confirm that there is not a duplicate custom field of the same name. As I mentioned above, this is the error I'm primarily battling with from my audit log:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Can do! Here is what I did:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ahh ok, thanks so much @Bill Sheboy! Unfortunately, this hasn't worked for me. I'm assuming it's because I'm not cloning in the "Same Project," but rather, I'm choosing a different project (original issue in "PF" and cloned issue in "PF1"). I think that's why I'm banging my head against a wall...same users with the same access and permissions to both projects, same field configurations, same screen configurations, yet I cannot get it to work. Thanks so much for your help, regardless! I'm just assuming at this point it's just not possible to do across projects with Jira Automation, at least at this time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
One more thing to check: is this a project-scope automation rule, or a global-scope rule? If this a project-scope one, I found an open defect for this problem/symptom:
https://codebarrel.atlassian.net/browse/AUT-1495
If this is global-scope, I believe that should work, and so please consider asking your site admin to submit a defect to Atlassian support here: https://support.atlassian.com/contact/#/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks again @Bill Sheboy for putting in all this leg work - really appreciate it! I bookmarked the Jira Public Tracker for Automation, now...but surprised through all my outside searching, I never stumbled upon that ticket somehow.
I altered the rule to test this out and it still does appear to be an issue for us here. I will be in contact with our site admin tomorrow. Thanks so much for your help!
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.