2.1.0-rc2 keeps asking to rebuild permissions

We stumbled on the same issue. I just had a very quick look in diff between 2.0.x and 2.1.x and this fella:
https://git.drupalcode.org/project/content_access/-/commit/d76340bda4aa6...
stands out to the naked eye.

I haven't fired a debugger yet to verify it, but node_access_needs_rebuild(TRUE); seems suspicious.

What did you upgrade from? It would be very helpful if you would use git bisect to figure out which commit caused this issue.

Try reverting the commit identified in #2 (d76340b) and see if that fixes it. I note that commit is in 2.1.0-rc2 but not 2.1.0-rc1.

@lpsolit when you say:

Drupal always asks to rebuild permissions for no obvious reasons.

are you changing content access settings and then this message is appearing, or is literally all the time? You rebuild the permissions and then the message re-appears without changing content access settings?

Yeah...bumping to critical because content access is going to prompt site owners to rebuild node access records every time a user's role changes, which can happen a lot!

This change was introduced in #3464095: Only show rebuild permission messages to users who can access link as far as I can see.
Specifically in https://git.drupalcode.org/project/content_access/-/commit/d76340bda4aa6... as @bserem helpfully pointed out.

As for why we even have that code...I don't know.

Why would the node access records for a node depend on the roles of a specific user? That's just weird.

I feel like if we can confirm that the node access records definitiely don't depend on any users roles, then we can remove that hook implementation since it was never really doing anything helpful.

Ah. The content_access_author realm. That's why content access needs to rebuild node access records if a user's role changes.

So...from my point of view content access has done this wrong, and we should change it. The whole point of the node access system is really to stop having to recompute the node access records when something about users changes.

I think we should:

• Remove the content_access_author realm
• Introduce new realms for each of the roles, for authors, so something like: content_access_author__developer or whatever
• When computing the node access records, we generate records for each of the configured roles that are allowed to view their own content, and the grant ID would be the node owner ID.
• Then when computing the grants a user has, for every role the user has, they get their own user ID as a the grant ID within the realm for that role.

That avoids having to recompute all the node access records when a user changes a role, and means that access changes are instant, rather than needing to wait for someone to do something too!

Probably needs some discussion with @quadrexdev

Has it been confirmed that the issue is resolved if commit d76340b is reverted? If that change is made, does the module work as well as it did previously? Perhaps that should happen and a more comprehensive fix wait for 2.2.x or 3.0.x.

Yeah you make a good point there. We could indeed revert that commit, or at least the part of it that's triggering the perisistent node access rebuilds, and then probably get a 2.2 stable release out. I don't think we've actually confirmed that it is the source of the issue, but from what I can see it looks very likely to be.

Then yeah, probably worth opening a new issue for re-working the content_access_author realm to be more sane and that'll deffo trigger a 3.0 release because that realm is probably considered API for this sort of module, and we'd be changing it etc.

I still think this is a critical issue though, because otherwise on a relatively busy site, you're going to be getting this message all the time!

I'm just relieved to find that I'm not the only one experiencing that.
In my case, an admin add / remove 1 role to users (members), and the Error gets trigger all the time...
Also glad to know it's critical.
Thanks for your work on that.

Yeah...the changes in that issue are not good. Flagging up that all nodes need to have their access rebuilt when any individual node's access settings are changed or when a user's roles are changed is not the way to go.

I've proposed a MR with the revert.

Ah, we want to do the revert like this: https://git.drupalcode.org/project/content_access/-/merge_requests/24

You don't need to close the merge request and open a new one. You can update the branch for the merge request and then force-push it. That will re-use the merge request the with the new code. The branches are the same anyway. Why put the feature branch in the main repo instead of the issue fork?

@liam morland thanks for the tips. I put it there mainly because gitlab gave me a nice 'revert' button on the previously merged MR, which I used because the branch in the issue fork was missing a lot of the revert commits. I took the easy path as a maintainer of the module.

No problem. I would expect the revert button to appear in the issue fork as well. Or it can be done on the command line. Either way has the same result.

This looks to be fine, I'm going to merge and cut a rc3 I reckon.

Can people following along give rc3 a go please? It should stop the message showing up quite so much for you, and then we can close this ticket down, look to get a 2.1.0 stable release out and then fix this issue properly in a 3.0.0.