Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Nodes that are created and assigned simple access permissions OTHER than View are then inaccessible to anonymous users, where the expected behaviour is that the node is visible to all.
The issue is that if access permissions are set, but not including any view restrictions, then gid 0 (all users) needs to be assigned view permission.
Attached patch adds this functionality. Basically, it uses a flag to see if the view permission has been limited. If it HASN'T but other permissions HAVE been set, then it adds the additional grant to the array that is returned.
| Comment | File | Size | Author |
|---|---|---|---|
| view.patch | 1.26 KB | Stuart Greenfield |
Comments
Comment #1
gordon commentedIf no options have been set for access control, then nothing is returned by simple access and Drupal creates a global access record.
This is doing so other access systems can set access for a node.
Use devel to check the access that has been set.
Comment #2
Stuart Greenfield commentedYes, if no options at all are set that works, and the access table gets a global record, but that is not the issue.
The issue is that if you assign access to something other than view, e.g. just give another group edit access without assigning any view restrictions.
Say I just grant edit on a node to group gid 3. The node should still be visible to everyone.
node_access now contains an entry for simple_access, gid 3, granting the update; an entry for simple_access_author granting everything; but there is now no view access assigned for anyone else and the node is no longer accessible to others.
With the patch in place if you then assigned edit access you get the above entries AND an entry for simple_access, gid 0, granting view. All users can now view, as expected.
If you then remove the edit access the table reverts to the global record for "all" (expected behaviour) both with and without the patch.
Comment #3
gordon commentedI now see what you are trying to do but the way that you have implemented this it will break other access modules.
eg. if you want to assign edit access to a node, and not assign view, your solution is giving access to all when another module like the og module may be assigning the view access.
This patch will break that. In this case I would create an all users group which include anonymous and authenticated which you can assign the view to when doing this.
Comment #4
Stuart Greenfield commentedHmm, I see what you mean.
The idea of the patch was to make the behaviour "intuitive" without needing an additional group in the case of simply wanting to assign some extra editors.
I've been thinking and can't come up with a way to circumvent the problem unless it were possible to know that another access module were active. If an additional module were detected then the extra simple_access grant could be suppressed. You would then need to make the access group if it were needed. That seems neat since you only need the extra group if you start combining access module, in which case your access controls are going to get more complex anyway!
I'll give it some more thought...
If nothing else I guess this is a "useful" patch for users running just simple_access!
Comment #5
gordon commentedThis is the way that Drupal's node access system works, and if we want to do something like this it is going to break simple access's interaction with other modules.
However 1 idea that I did have it to allow you to set up permission profiles, eg, groups "all view" gets view access and and editors gets edit access.
These can then be picked quickly to set the configuration that you want.
Comment #6
gordon commentedIn v2.0 I have added profiles which covers this functionlity.