Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.If the administrator grants View access to anonymous and authenticated users, CA creates a grant in the 'all' realm, as core does for nodes that receive no grants whatsoever. In the presence of other grants, however, this is most confusing.
The cooperative architecture of Drupal's node access mechanism relies on the contract that every module supplies its grants under one or more realms of its own, and the 'all' realm belongs to core.
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | content_access-239139-20-D7.patch | 1.39 KB | gapple |
Comments
Comment #1
masipila CreditAttribution: masipila commentedIt seems to me that this behavior of Content Access module is the reason why my forum access control broke after I updated Content Access and Forum Access modules.
See http://drupal.org/node/215563#comment-807818
Are there any workarounds for this issue?
BR,
Markus
Comment #2
masipila CreditAttribution: masipila commentedJust to let you know that I found a workaround for my problem.
See http://drupal.org/node/215563#comment-809915
-Markus
Comment #3
fagoIs this really causing any problems? This linked problem seems to be fixed.
Re-using the existing 'all' realm avoids complicating the query - so it speeds up things a bit.
Comment #4
fagoComment #5
salvisThe linked problem is fixed by FA specifically checking for CA and informing the user that he should not try to use CA on forum topics at the same time as FA. This should help FA users, but it doesn't solve the general problem, which is that people don't have a chance to understand what is happening when they see an "all" grant.
How does a NID/all/0/100 grant speed things up over a NID/content_access_all/0/100 grant?
Comment #6
fagothe query just needs to queck for 'all' and not also for 'content_access_all'.
>fixed by FA specifically checking for CA and informing the user that he should not try to use CA on forum topics
hm, reaming it wouldn't change here anything or? Users never see the realms anyway.
Comment #7
salvisWithout devel_node_access it's impossible to find out what's happening, and with DNA you see the realms — except if a module like CA masquerades, then you still can't find out what's happening. At least the users can't. Not showing your face results in confusion and unnecessary support issues. This will be a nightmare for FA, when you port CA to D6, because D6 forums can contain all sorts of content types, so CA will constantly be interfering with FA.
This is neglegible in most cases. Depending on how many roles you have, there are 10, 20, 30, or more realm/gid pairs to check. One more or less doesn't make any difference. Look at the debug output of DNA. For example, not creating an empty unused ACL record (plus three {acl_user} records each) for each node would make much more of a difference...
Comment #8
fagook, you have convinced me. However I don't think it's a good idea to change this in 5.x - as we would need to rebuild the whole node access and we know what troubles this can cause for users of big sites...
So I'd suggest we fix this in 6.x?
Comment #9
salvisGreat. Yes, I agree that it's not worth the risk for D5, but with D6, rebuilding permissions is not an issue, and node access can be a lot more complex.
So, yes, please do fix it for D6 — thanks in advance!
Comment #10
salvis@fago: So, what became of your resolve to fix this in 6.x?
Comment #11
Leksat CreditAttribution: Leksat commentedsubscribing
Comment #12
good_man CreditAttribution: good_man commentedThis needs to go into 7.x then backport to 6.x with update and any changes necessary for documentation.
Comment #13
BenK CreditAttribution: BenK commentedSubscribing
Comment #14
good_man CreditAttribution: good_man commentedEasy fix, big impact on compatibility with other access modules.
Committed to 7.x.
Comment #15
good_man CreditAttribution: good_man commentedThat fix is committed to both 6.x and 7.x, please test it and tell me if it works for you.
Comment #16
BenK CreditAttribution: BenK commentedI tested this out in D7 and there's a problem with this recent commit...
It's causing all users except those with the "bypass node access" permission to be prevented from viewing the node. This is occurring even when the per node access control settings should be giving all users view access. And I've confirmed via the Devel Access block and Devel Access by User block that this recent commit causes all users except those with bypass node access to be denied.
And I confirmed that removing this commit resolves all observed issues.
Seemed like a simple commit, but was there some type of bug in the implementation? If we can't figure it out quickly, we probably should just reverse the commit for now as it causes the module to be unusable (unless you don't want your users to view any content).
Thoughts?
--Ben
Comment #17
oriolo76 CreditAttribution: oriolo76 commentedsee also here:
http://drupal.org/node/1213148
Comment #18
MichaelCole CreditAttribution: MichaelCole commentedComment #19
good_man CreditAttribution: good_man commentedCommit reverted, let's get back to work.
@MichaelCole: don't change the status if there is no real change in the issue flow.
Comment #20
gappleIt looks like the issue with the previous patch is that hook_node_grants was not changed to specify that all users should have access via the new content_access_all grant.
I've attached a patch for 7.x, should apply for 6.x as well.
Comment #21
gappleMarked the following issues as duplicates:
#1213148: Access denied to all content for anonymous users
#1212718: View any content does not work when the Anonymous + Authenticated are both checked
Comment #23
gislePatch fails to apply to HEAD, but it is simple enough to apply manually. However doing so makes testing fail.