Hi Atlassian Team,

We are facing same issue in 7.3.8 JIRA version also
Log messages i am getting continually, since we are using non editable property in many closed tickets
====================================================================================
2017-08-02 17:22:42,015 Caesium-1-1 ERROR userID [c.o.s.c.jira.utils.WorkflowUtils] Not attmpting transition
2017-08-02 17:22:42,018 Caesium-1-1 ERROR userID [c.o.s.c.jira.utils.WorkflowUtils] Errors: {}
Error Messages: [You do not have permission to edit issues in this project.]
=====================================================================================
even though user is JIRA admin

Please confirm how to avoid these errors or will this error cause any issue related to indexing or any other problems

Thanks,

Balvant

For us the issue is also not resolved in 6.2.5.1, Please advise if something needs to be configured first to avoid this Error

Please provide information on how this issue should be fixed in 6.2.3. We are still experiencing this problem in 6.2.5. see related issue for a possibility to implement a real solution.

The default JIRA workflow often catches people out like this. Or more precisely the jira.issue.editable property does. I wish it could be easily disabled for admins to make changes, and was more obviously present for other users.

verified the user message

I may have a work around. The 'Epic Status' field is independent of workflow-driven Status. But workflow will block 'Mark as Done' for Epic Status if you have CLOSED the Epic, just as it would block updates to any other field.

My workaround was to attach a new workflow that allows edits on Closed EPICs. This requires modifying the CLOSED step's properties.

This will only work for JIRA teams that:

• are familiar with Workflow editing
• can live with 'CLOSED' EPICS being edited (keep in mind, you will still know who made the modifications, per activity log).

We have not tested this out completely, but the workaround appears to solve the issue described here, which we encountered at AKC.
As is probably the case for many, we were using the JIRA default flow for EPICS, to keep things simple.
I kept the flow identical to JIRA default EXCEPT for the properties modification.

Hope it helps. I will add an update if we encounter issues in testing.

Hi james.caldwell@disney.com - the best way to get this looked at immediately would be to contact Support for assistance: https://support.atlassian.com/ - let me know if there's any issues.

Regards,

Chris

This is happening in several of our Jira instances. It runs contrary to how most folks think.

Is there additional information we can supply to get this resolved?

Happens in our JIRA/Greenhopper as well.

I cannot reproduce this when the Epic is in the Closed status. Are there some further permissions in play here?