status properties vs project permissions

[Deleted user]

Hi,

In our scenario the reporter raises an issue and after that it goes through an approval flow via several issue status. Once this approval started, it should not be possible anymore to edit the issue. (Scenario B: it is only possible for project admins role)

First I allowed the project role "Administrators" and "Reporter" to edit the issue within the project permissions:

then I tried several ways to block editing for certain status via the properties:

Property key: jira.permission.attach.denied
Property value: (empty)

or

Property key: jira.permission.edit.projectrole
Property value: 10002 (Administrators)

I also tried to limit it to a certain JIRA Group. The result was always the same: If the issue is in the relevant status, the project admins cannot edit the issue anymore but the reporter is still able to edit the issue.
With this setup I would expect, that the blocking overrules the permission within the project permission, but it is not working.

What am I missing here?

Thank you for your help.

[Andy Heinzer · Accepted solution]

update:

Workflow status properties will no longer support group names

As of 8th of September 2023, we’re removing the ability to use group names shaped like jira.permission[.subtasks].{permission}.group.[.suffix]in workflow status properties. Entities that haven’t been translated from group name to group ID will no longer work as expected.

To ensure we can rename groups safely, we no longer support group names in status properties.  If your workflow uses a status property with the shape jira.permission[.subtasks].{permission}.group.[.suffix], your admin will have to change the value to the group’s ID.

Site admins can find a group’s ID by going to Settings > User management > Groups. After selecting a group, the ID will be at the end of the URL.

If your app uses the above workflow status properties, you’ll need to update your code to use group IDs instead of group names by the end of the deprecation period on 8th of September 2023.

Original answer:

---

Hi,

I see that you are looking to try to restrict at which stage a reporter can edit an issue in Jira, and when they cannot.  The workflow properties can still be used to make this work the way you want here.  In my own Cloud site, under the project settings, I went into the workflow in question, found a specific status (I picked 'In Progress'), then clicked the View Properties.

I added the property key of

jira.permission.edit.group

and the property value of

site-admins

However there is another step that is needed here that is frequently over looked.  And that is, we need to publish the workflow again after this change is made.  That isn't always as obvious as it should be, I admit.  But if you go back to then edit the workflow itself, you should see a prompt at the top asking you to publish this draft, like so:

If you click that Publish Draft link, you see a dialog like this, you can certainly make a backup of your workflow first, but in this case I did not for my testing purposes.

Once that is done, only site-admins will be able to edit that issue in that workflow when it is in that specific status.

I hope this helps.

Let me know if you have any concerns about this.

Andy

[Deleted user]

Hi Andy,

thanks a lot!

Sometimes the solution is too simple :) Now it works as expected.

Thanks.

Christopher