I've been trying to restrict edit access for issues at a specific status via the Workflow status properties. I can't seem to figure out what to add to give the "Automation for Jira" user edit access. I've tried both (not at the same time): * jira.permission.edit.user = Automation for Jira * jira.permission.edit.user = 557058:f58131cb-b67d-43c7-b30d-6b58d40bd077 Neither seem to work. I've confirmed that "Automation for Jira" is able to edit the respective issues when I have no properties set. But when I set these properties to try to restrict edit access to ONLY "Automation for Jira", nothing is able to edit the respective issues - including the "Automation for Jira" user. Something I'm missing?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workflow Properties to Only Allow "Automation for Jira" User Edit Access

Will Thompson_5up1qo

I've been trying to restrict edit access for issues at a specific status via the Workflow status properties. I can't seem to figure out what to add to give the "Automation for Jira" user edit access.

I've tried both (not at the same time):

jira.permission.edit.user = Automation for Jira
jira.permission.edit.user = 557058:f58131cb-b67d-43c7-b30d-6b58d40bd077

Neither seem to work. I've confirmed that "Automation for Jira" is able to edit the respective issues when I have no properties set. But when I set these properties to try to restrict edit access to ONLY "Automation for Jira", nothing is able to edit the respective issues - including the "Automation for Jira" user.

Something I'm missing?

Accepted answers

Bernhard Reiter

You have to use

Key: jira.permission.edit.projectrole

Value: ID of the project role of "atlassian-addons-project-access"

Bildschirmfoto 2021-12-17 um 16.32.10.png

Bildschirmfoto 2021-12-17 um 16.37.55.png

Bildschirmfoto 2021-12-17 um 16.38.36.png

All comments

Imdad KP

Hi @Will Thompson

Try this in status property

Property Key: jira.permission.assign.assignee

Property Value: assignee

Will Thompson_5up1qo

Hi @Imdad KP

I'm curious, what would this do? The "Automation for Jira" user is not the assignee for the issue (and I don't want to make it the assignee).

Imdad KP

Hi @Will Thompson

Can you share the screenshot of the configurations you have created? Then, I can share the exact configuration that I have mentioned above.

Will Thompson_5up1qo

Not sure what this screenshot will tell you that my original post didn't, but here you go:

Screen Shot 2021-10-13 at 6.08.52 PM.png

Bernhard Reiter

You have to use

Key: jira.permission.edit.projectrole

Value: ID of the project role of "atlassian-addons-project-access"

Bildschirmfoto 2021-12-17 um 16.32.10.png

Bildschirmfoto 2021-12-17 um 16.37.55.png

Bildschirmfoto 2021-12-17 um 16.38.36.png

Dace Petersone

Hello,
I have same need as described initially as Secure level adding is not the choice (Issues must be visible for any project user, but editable for 1 project role (this is clear how to do) and for Automation for Jira only).

Dace Petersone

The right Automation for Jira ID can get from Quickfilter assignee = Automation for Jira.
Your number format looks correct.
jira.permission.edit.user
557058:f58131cb-b67d-43c7-b30d-6b58d40bd077

Actor of the Automation rule = Automation for Jira.

I tested few cases, it looks this works.

Matt Houck_65e3n8

This was perfect and took me way too long to find. I could not get these specifics from any of the Atlassian documentation I found. To me it would seem that 'Value' information like this should be easier to find.

Matthew Przeslicke

Thank you so much. This has been the only working solution to the automation "field history logging" problem I've been struggling with for too long:

Work Item is set to [Status] with (previously) Read only property (instead of the above solution)
User activates recursive transition to reveal Edit screen
User completes and confirms CustomField_X edit
Automation logs and appends change to CustomField_X_History:
[NewValue3] -- [Time/Date3] [Editor_Username3]
[PreviousValue2] -- [Time/Date2] [Editor_Username2]
[PreviousValue1] -- [Time/Date1] [Editor_Username1]

Step 3 would succeed, but Step 4 would fail. The automation audit would list the field as unavailable/not present. It was being blocked by the Read only status property, making the rule fail. Adjusting the status property as directed above completely resolved this.

Jira Forum - 1, ChatGPT - 0.

Thank you again!

I award you no infinite points, may God have mercy on a party with your soul.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-work-management