Hello,
I was setting up a rule to copy the change of a field to the same field in the epic of the task.
The actor of the rule is set to the user who triggered the event.
When I update the field with my admin user, I will be shown in the history of the epic as the user who updated the field. Thats how it shoudl work.
When I perform the rule as a "normal" user, "Automation for Jira" is shown as the actor in the histroy of the epic.
The "normal" user has all the needed permissions to work on and change issues.
Could someone tell me why the normal user is not shown in the history?
Thank you!
BR
Niklas
I wonder...rules which have been edited too many times can get "glitched" by the rule editor. (There is no explanation why other than something gets broken in the saved rule.) Let's try this: disable your existing rule, re-create your rule as a new one, and then re-test to observe the results.
Kind regards,
Bill
hey @Bill Sheboy ,
thank you very much.
I re-created the rule and now it works!
Thanks to everybody!
BR Niklas
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Bill Sheboy !
This question, and the fact that until now no good explanation was coming forward, had been nagging me for a while. Thanks for giving this a happy ending :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Niklas Borgstedt would it be possible to attach some screenshots of your automation for review? Sometimes another set of eyes may find something. Thanks,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Dan, thanks for the reply.
In the meantime I found the solution and Im not very happy with it.
The user needs the permission "Administer Project" to be the rule actor.
I just dont get why, when the rule is about changing fields in issues.
Maybe somebody has an explanation to this?
Thanks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That approach seems curious to me, and perhaps indirectly related to the actual cause of the problem.
Please post images of your complete rule, showing all actions, and of the audit log details showing the rule execution when it does not work. Those will provide context to help track this symptom down. Thanks!
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This made me curious so I ran the scenario through our sandbox. I was able to get epic history to show that the field was edited by the designated rule author, independently of the "administer project" permission.
Could there be other permissions in the permission scheme that the actor is missing?
Here are the steps used in replicating this
The project uses the Default Software Scheme permission scheme
1. I created a custom field "test field", single line text field
2. Seleted a project with open epics and and task children and added the new field to both epic and task screens
3. Created the automation rule detailed below
4.Wrote "test" on the Task child "Test field" with my admin user account
5.Epic "Test field" was updated by automation showing me as the actor
6. Cleared the "test field" field in both Epic and Task
7. Logged into a user account with no admin privileges and no role in the project
8. Repeated step 4 with the new user
9.Epic "Test field" was updated by automation showing the new user as the actor
Here is a screenshot of the Epic history (the non-admin user is called "Jira Updater")
And below is the history of the Child Task
And finally, the automation log (the collapsed entry was for when the field was cleared in step 6
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Diogo,
thank you very much for your help.
Here is my rule:
In the Audit Log, it is always a success, but the performing user is "Automation for Jira"..
I have tried every single permission to get the user in die history log. The only one working is the "administer project" permission..
BR Niklas
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is essentially the same configuration I used in the staging instance. If we both have identical automation rules and one is not producing the intended results, then the logical conclusion would be that some other configuration element is affecting the end result.
You have already checked the permissions. Just to double check, have you tried editing the destination field in the epic directly, using the user account of the non-admin user? Can they do it?
If they can't, then Automation won't be able to use that user as an actor. Even then, though, the rule would just fail to execute.
I'll do some more testing on my side and will let you know if I can replicate the issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @Diogo Teles ,
Im back from the holiday and tried it one last time.
1. Created test project
2. Created Test User
3. Created the automation rule like mentioned above.
4. Gave the test user every single right except for the right "Administer Project"
5. Changed a value in the child-task
Result = "Automation for Jira" changed the field in the epic
6. Give the test user the right "Administer Project"
7. Changed a value in the child-task
Result = "Test user" changed the value in the epic
Im currently out of ideas how to fix this..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Switch to Jira Cloud with Atlassian University! Explore new navigation, issue views, and Cloud features like team-managed projects and automation. Tailored for Data Center users & admins, these courses ensure a smooth transition. Start your journey today!
Enroll now
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.