Looks like /rest/api/3/mypermissions returns old data, after making changes to user group membership (maybe there are more other cases), so that user permissions are changed, e.g. Edit All Worklogs. So user does not have Edit All Worklogs permissions anymore, but api says user still has the permission.
Scenario:
Prerequisites: user is member of Administrators project role via administrators group, so has Edit All Worklogs Permissions
Remove user from administrators group, so that you don’t have Edit All Worklogs permission.
Open an issue, Worklog tab, with other users workogs, see Edit link for other users worklogs. Expected no edit link for other users worklogs.
Wait for a while (half an hour?), refresh issue, see NO Edit link anymore for other users worklogs
The Jira team tried to reproduce this issue, but couldn’t. Here are the steps they took:
Invite a new user, Foo, to a Jira Software tenant.
Grant administrators role to user Foo.
Project admin adds an issue in that project. Switch to old view and add work log description.
Verified user Foo can see the issue, work log desc, and able to modify it.
Verified that permission helper utility (select Permission helper from the Admin dropdown menu and select “Edit All Worklogs” from the “Permission” dropdown) and /mypermissions API confirming the same.
Project Admin removes the administrators role for user Foo and checks his grant status on EDIT_ALL_WORKLOGS permission via permission helper and it says user has no access.
Verified user Foo cannot edit other’s worklog desc and /mypermissions API returns hasPermission value to false for given permission and issueKey.
Are you able to follow the same steps to replicate this or do you see different behaviour?
An only (essential) difference from my steps, is that I take existing user, as I can’t create new user.
Note, I don’t change issue view, and have Classic Software Project, but I don’t think it’s essential. And I remove administrators role for the user via group membership, but I have tried adding and removing user directly to/from the role, and I still get the same problem:
/mypermissions still returns havePermission: true, after removing administrators role from user, however UI (issue view) reflects changes immediately now.
Thank you for letting me know, but the problem still persists on my timereports.atlassian.net instance. API returns havePermission: true, but I don’t have the permission and this looks correctly in UI.
Just FYI that I also experienced many problems on my dev Jira instance that were not reproducible on other instances.
You might try to reproduce it on another Jira first to make sure it is a common problem.
Just a quick update that we are still looking into this. The Jira team can reproduce this issue, however, they observe a delay of just a few seconds as opposed to your delay which is in the order of hours.
Hello @azhdanov, I’m currently looking into the issue you are facing. This is somewhat aligned with our current plan to improve the overall performance of the Jira cloud.
The identity change is polled every 4 hrs, so such a delay is expected. As for your problem, I need to know whether you are facing this problem consistently and what is the average time it’s taking to reflect the changes.
Well, in my case it looks like not a delay, but as if identity change was not noticed ( was lost ) by the permission rest api. So that it looks like havePermission is never going to return false, at least it still returns true.
And yes, behavior is consistent, api did not see the changes to the permission at least for 5 tries.
And the problem is with azhdanov@gmail.com, but only wit the REST API, i.e. UI reflects permissions correctly with a delay, as you observe it too, see screenshot on my second (BUMP) post, with accountId depicted.
Hi @azhdanov, it looks like your tenant is having an issue with the identity polling as I mentioned earlier. I’ve forwarded your query to the respective team. I’ll update you as soon as I find the resolution.