Edit forbidden error, but not all the time.
Asked by Curt Holley:

Anyone else experienced this?   
I'm getting occasional errors from a rule and the detail in the audit log is "edit forbidden". But this only happens randomly. Below is a good example, where in a short period of time, in the same Project (it's a global rule) there was a successful, a No action performed and a "some errors" with this stage error.  
The field "StatusChanges", is read only, as in, it isn't configured for "Edit screen" so that people cannot manually mess with the entries added by the rule. This works...absolutely! and as shown below, works in this project only minutes apart.   
So what could it be? Any ideas [@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313) or [@Mykenna Cepek](/t5/user/viewprofilepage/user-id/3527113)

![forbidden.png](https://community.atlassian.com/t5/image/serverpage/image-id/189046iA997D423241B5130/image-size/large?v=v2&px=999 "forbidden.png")


Answers:
author: Mykenna Cepek
body: Here are the clues I detect: global rule (i.e. will run for various projects using various project configurations), intermittent errors, and the inability to edit an issue.

This suggests that there is a configuration difference between projects causing this problem. You will probably also see consistency in which projects have this error, and which projects do not.

I would check these areas, comparing between projects that work and projects that don't:

* Difference in Permission Scheme (preventing the issue from being edited)
* Difference in screen or field configuration (preventing the field from being accessible at all, or from being editable)

Also check how this rule is configured for the "Actor" field. Ensure the configured Actor has the required access to perform this edit.

A helpful thing for situations like this is the Jira Permission Helper:

<https://YourInstance.atlassian.net/secure/admin/PermissionHelperAdmin.jspa>

(the above is the Jira Cloud link; replace the YourInstance part to match your Jira).

It can easily pinpoint many configuration details that can prevent a user from taking a specific action on a specific issue.

Let us know what you discovered!

comments: author: Doug Levitt
body: Please note, I have also seen this issue intermittently (but definitely ++not++ often). It occurs when the Jira system is unstable (due to high volume).


author: Curt Holley
body: Thanks [@Mykenna Cepek](/t5/user/viewprofilepage/user-id/3527113) I have checked most of those and indeed i do get "explainable" errors from time to time with such (global) rules. But in this case, their is no consistency as the screenshot demonstrates (3 examples all in the same Project, where 2 out of 3 work, one doesn't)  
I did this morning wonder if it is as [@Doug Levitt](/t5/user/viewprofilepage/user-id/3570640) points out, that it is to do with traffic/volume/stability of Jira at a given moment. Based on this occurring yesterday [Jira Software Status - Various features are not working for some Atlassian Cloud customer](https://jira-software.status.atlassian.com/incidents/0wqjnrr4tx8c) around the time I started getting seemingly random failures.

Thank you both for responding!!!


author: Doug Levitt
body: [@Curt Holley](/t5/user/viewprofilepage/user-id/3527535)

I typically ignore intermittent errors (that is, it usually works, but rarely doesn't). Occasionally, I need to manually modify a Jira ticket to address the "data corruption" (i.e. data is not in the state I would normally expect).

Because I anticipated the Automations not being 100% reliable, I have implemented a set of Monitors for each important automation. Each Monitor checks for deviations which should not occur if the original Automation was successful.

Examples include:

- Monitor to check synchronicity between PBIs and SubTasks (where a PBI is a Story, Bug, etc.)

- Monitor to check synchronicity between Epics and PBIs (where a PBI is a Story, Bug, etc.)

These monitors write warning to Slack Channels. I spend about 5 minutes each day scanning these and making corrections if needed.

As a note, we have \~ 225 developers across 30 Squads, running in synchronized Sprints.