Fixed Permissions Not Updating

[Ghan_04]

Greetings.

We're experiencing an issue where when changing certain permissions (namely in this case, user permissions on nodes - for example, adding View Node on a private node for a user or making a user a moderator of a forum) do not update right away after being saved. After about 3 hours of troubleshooting, I believe I have ruled out any browser or server-side caching issues.
I am able to get permissions to update by either installing/uninstalling an addon or by altering the permissions of a usergroup to which the user belongs (other usergroups don't seem to help). It sounds like some kind of permission cache isn't getting cleared or rebuilt in the DB, resulting in stale permissions getting used, but I could be way off base. Any ideas on this one?

PHP: 5.5.0 w/OPcache
MySQL: 5.6.12
Nginx 1.3.14
Varnish 3.0.4
Memcached 3.0.8

Thanks.

 

[Mike]

What XenForo version?

 

[Ghan_04]

1.1.4

 

[Mike]

Well, the code here has changed significantly for 1.2 (handling it more like the rebuild processes), so from a bug perspective it's most likely resolved. I'm sort of surprised you're not getting an error if it's the issue I'm thinking (or with that error, the save shouldn't go through).

In 1.1, the only recommendations I could make for working around it involve reducing the number of unique "permission combinations" and/or nodes that you have, though obviously that's not ideal.

 

[The Dark Wizard]

Well, the code here has changed significantly for 1.2 (handling it more like the rebuild processes), so from a bug perspective it's most likely resolved. I'm sort of surprised you're not getting an error if it's the issue I'm thinking (or with that error, the save shouldn't go through).

In 1.1, the only recommendations I could make for working around it involve reducing the number of unique "permission combinations" and/or nodes that you have, though obviously that's not ideal.

That is less then ideal alright.

On our site we promote/demote people to moderators of their forums on a daily basis. We need to be able to do that since people come to our site to run their campaigns for Dungeons and Dragons and other forms of Roleplaying Games(The moderator is the storyteller).

We have been able to replicate the same exist issue on our 1.2 beta 3 environment as well as the live site as Ghan stated.

 

[Mike]

Well I do note that I haven't seen this reported before (at least not without an indication of an actual error occurring). If you want to submit a ticket with admin CP and FTP details and instructions on how I can reproduce it, then I can look into it.

 

[The Dark Wizard]

Well I do note that I haven't seen this reported before (at least not without an indication of an actual error occurring). If you want to submit a ticket with admin CP and FTP details and instructions on how I can reproduce it, then I can look into it.

Sure!

We will do just that.

 

[The Dark Wizard]

All done.

 

[Mike]

Moving this back while I look into a fix. This was caused by there being out of date permission combinations there, but it caused the system to update the one that wasn't actually attached to the user.

This can be tricky to automatically fix, but it's relatively easy to sort by removing the extra rows.

However, tracking down why it happens is important. I think it may only occur after deleting a user group that a user is a member of while they also have user-specific permissions.

 

[Mike]

The cause for this is fixed in 1.2, though it's not necessarily retroactive.

1.2 also adds a tool to identify unused permission combinations and to clean them up. In some scenarios, this can significantly speed up the permission rebuild process.