At my company, Jira is set up quite restrictive, with quite strict workflows.
One of these workflows is the automatic transitioning of issues from "Code review" to "QA" status when PRs are merged in Bitbucket.
This bypasses the option to transition issues in the Bitbucket "merge PR" popup. It should be noted that for some reason, my Jira account is not allowed to transition issues from "Code review" to "QA" manually. Annoying, but fair enough.
However, something is automatically transition these issues, and in the issue history this shows as *my user transitioning the issues*.
I have big ACL concerns about this. I have no visibility whatsoever on these automations, and the automation acts, as far as I can see, *with the privileges of my user*. I can't see the audit logs of the automation, but I assume the audit log will show the issue being transitioned by my user.
In a hypothetical scenario, a privileged actor with malicious intent could create a "nuke the project" automation, and set it up so it triggers when I e.g. merge a PR. In the audit logs, this will show up as "<my user> nuked the project".
A tool with proper ACL should not allow such a scenario to happen.
Hi @seppe and welcome to the Community,
this is why access to Automation can be restricted. This is a global permission that a user needs *in addition* to being project admin.
Are you a project admin? Then you should be able to see the Automation rules in Read-only. Otherwise contact one of the Jira Admins and check what's going on. It's not nessecarily an Automation but could be a Script as well.
It's hard to tell from afar - even with your detailed description.
Jira has a lot of possibilites for restricting access to data & functionality, but is often not set up correctly/to suit the companies need for governance.
> Are you a project admin
No, I don't think I am. I have developer access to the project.
Of note though is that the "automation" is likely global, as in across more than just the project I work on.
Regardless of the configuration, IMO a tool that uses ACL should never allow actions to be done in a users name, without the user being aware of these actions.
If my user is not able to transition issues from "PR" to "QA", any tool should not be able to do so *in my name*. It is at best confusing, and at worst could be used to frame users for things they didn't do (by people who have a higher level of access).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That situation should not happen with an Automation as that respects the rule actor's permission - so I kinda doubt that it's automation. OR the transition is only hidden from you but you are allowed to use it.
Sounds like a bit of a weird setup anyway. I cannot speak to what Jira should allow or shouldn't but that type of flexibility is needed in a lot of scenarios while it's a hinderance in others.
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.