Constantly needing to rebuild permissions since updating to 7.x-1.2

This behaviour is a consequence of how this bug: 🐛 "content_access_author" grant does not react to role changes Fixed was fixed.

I don't believe it appears out of the blue. It appears after one of the site's administrator change the role assignment of at least one of the user.

The fix is not very elegant (it would be better if the permissions rebuild happened automagically, instead of prompt the administrator to do it), but this is what we were able to do with the resources that were available. You, and other users, are welcome to open a new issue if you think you know how to solve this better.

Before the parent issue was fixed, this was a security problem. Users that were removed from a role would still have access to content available to that role until permissions were rebuilt.

Hi there,

I'm also suffering with the continuous alert, so here is the solution.

- It does not affect all the nodes on the site, only the ones which were created/owned by the modified user(s)
- It collects the records to a separate table and will rebuild their permission
- It defines an admin interface where admins can set to update permissions during cron jobs (admin interface defines new permission)
- It doesn't trigger the node_access_needs_rebuild() since that call would update all nodes
- Admin can run the rebuild permission batch process manually, but it only updates the affected nodes

I hope it helps.

Thanks for the patch!

We need somebody using the D7 version to review it.

It probably also need porting to the D9/10 version.

@danyg this is a great patch!

The logic in this patch is sound, and it works like a charm on my sites.

I have made a handful of modifications to make the wording clearer and fix code formatting.

There is one concern here which is that the original change made in 🐛 "content_access_author" grant does not react to role changes Fixed that was released in 7.x-1.2 has been public for a few months, and some site admins may be depending on the notification message in that release to indicate that permissions need to be rebuilt. Since the change in this issue removes that message, I think it's better that content_access_silent_rebuild defaults to TRUE. And since the changes here only update certain nodes, enabling this by default shouldn't cause performance problems. This change has been included in my patch.

Due to a code change in 🐛 Convert settings from serialize to json_encode Fixed , this patch needs an update to account for the change in content_access.install.

I also took this opportunity to clean up the new schema table definition and move it into content_access_schema().

The two differences between this patch and #5 are:
1. Increase the hook_update_N() version number to 7104.
2. Move the the new schema code into content_access_schema().

I've reviewed the patch in comment #6.

1. Patch applies cleanly.
2. It adds a new configuration setting. This setting must be documented in the README.md.
3. Change has security implications. Administrators need to be told about this, both in the README.md and in the decription on the configuration page.
4. When enabling "Allow background permission rebuild", patch works as expected (permissions are rebuilt on cron).
5. When disabling "Allow background permission rebuild", I'd expected the administrator to be reminded that permissions need to be rebuilt after changing a user's role. However this does not happen.

I've attached a new patch that addresses items #2 and #3.

However, we need to administrators that do not enable background permission rebuild that they need to manually rebuild permissions after changing a user's role that affect node permissions (item #5). This must be done. Setting status to "Needs work".

Hi,
After to apply the patch (#7) and run updb, i tried to access to "admin/config/system/content_access" I got "You are not authorized to access this page." i tried to rebuild permissions too, but I can't got the page for enabled "Rebuild permissions in the background during cron runs", please let me know if I do something wrong

Hi @drw, we introduced a new permission (rebuild node access permission), you need that permission to reach the admin page.

Hi @danyg
Thanks for the reply, it works like you said.. I forgot set the new permission for my user(role)
I tried with 1.2 and 1.3 version and works admin/config/system/content_access with the new permission

This works correctly on our system. What is preventing this patch being elevated to a release?

See commet #7.

Here is the updated patch, extending the last patch (#7), adding the suggested reminders to administrators.
Now it warnings the admins if the "Background rebuild" is disabled and also notify admins to run rebuild process when a user is being updated and the automatic rebuild is turned off.

Automatically closed - issue fixed for 2 weeks with no activity.