Postponed
Project:
Content Access
Version:
3.0.x-dev
Component:
Code
Priority:
Minor
Category:
Plan
Assigned:
Unassigned
Reporter:
Created:
21 Oct 2020 at 15:13 UTC
Updated:
6 Jul 2026 at 13:55 UTC
Jump to comment: Most recent
Problem/Motivation
Getting the message about rebuild after saving changes to access control for a single node. Is this ever true? The ContentAccessPageForm displays this message for all saves. Are there are any cases where a single node access update requires a full rebuild? Maybe this message is in the wrong file?
Steps to reproduce
Enable "per-node" access control for a given content type. Edit a node of that type, use the Access Control tab to change the settings from the default for the content type, and save the node access change. Receive the message "Your changes have been saved. You may have to rebuild permisions for your changes to take effect." (note typo in spelling of permissions)
Proposed resolution
Remove this message if it is indeed spurious. Or move it to the ContentAccessAdminSettingsForm file.
Issue fork content_access-3178212
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3178212-check-rebuild-access
compare
Comments
Comment #2
john.oltman commentedComment #3
john.oltman commentedComment #4
john.oltman commentedComment #5
gisleI can see that this is annoying.
However, looking at the module's history I can see that some of these were inserted out of desperation when some maintainer tried to get to grips with various "inexplicable" security issues affecting the module. Notice that is just a suggestion. It says "You may have to rebuild permissions for your changes to take effect", and not "You must rebuild permissions for your changes to take effect".
However, debugging the Content Access module is more time consuming than my schedule permits. I signed on to maintain this in order to get in a usable state, not to fix every flaw, and this is fairly cosmetic. Feel free to ignore the suggestion.
If anyone of this project's users can come up with a plan for how to QA a solution to this issue, including a well-designed test suite that convincingly makes the case for the removal of some or all of these, I'll make sure that the changes are committed. However. I cannot find the time to work on this myself.
Postponing for now. Feel free to assign yourself to have a crack at solving this.
Comment #6
gisleI've fixed the spelling of "permissions".
Comment #7
gisleThis should go into the the most recent branch.
Comment #8
drupgirl commentedThis message is quite confusing for end users. It's a "success" message that reads/acts like a failure. Imo the simplest solution is to send this message to the system log and remove the message from the user.
Comment #9
gisleIt has been a lot of water under the river since I wrote comment #5 (in 2020), and it turns out that not rebuilding permissions when it is required may in certain situations constitute a security vulnerability. See the related issue #3357181: Does not react to role changes for background.
It would be much better if somebody could find some time to drill down into this, identify the situations were rebuilding permissions are required, and identify those when it is not. However, until somebody does this (see suggestions for how to proceed in comment #5), these messages stay in the user interface.
Comment #10
alienzed commentedYou'd think that, instead of displaying this message to end users who cannot do anything about it, that a Rebuild Permissions would just be triggered, period. No?
Comment #11
gisleYes. An MR/patch that does trigger rebuild permissions in the right context shall be welcome.
Comment #12
steven jones commentedMoving to 3.0.x.
Now that we've sorted out the author realm/grants in #3579507: Re-work the author grant realms I suspect that we can remove the 'may' from here.
If you're saving an individual node's settings, then that should be sorted.
Otherwise, if you're saving a node types settings then I think we should flag for a rebuild, and remove our own implementation tbh.
But that's probably another ticket.