Content Access set for each content-type, but doesn't work

i have the same problem, i dont allow anonymous users to see one specific content type, but its displayed and accessible anyway.

I was hit by this as well. I haven't quite wrapped my head around it yet, but maybe Panels, by design, ignores the content access settings.
In my case, the workaround was easy, just add a variant that redirects all anonymous users to the frontpage, or give them a 404, or whatever you want.

Threesa, does the problem go away for you if you disable Panels?

I asked on IRC:

<merlinofchaos> content_access just adds stuff to the node_access table. That should all still be respected.

So currently there's not really any reason to suspect Panels is to blame. If someone can show Panels is however, move the issue over to the Panels queue and I'll look into it.

Threesa, does the problem go away for you if you disable Panels?

?

For some reason anonymous users still see the normal content...

Can you be more clear what is the content type that is viewable by anon.? or all of them?

btw i didnt use panels and still had this problem.

Guys, can we be more clear what steps you made to duplicate this on my dev machine. Because I can't see that bug on your machines, I can't fix it. If you don't provide steps you made to get into this situation I can't fix.

I have this problem too.
I installed Content Access module and when I set permission so that anonymous users cannot see some nodes, they can see them anyway.

Domain Access module is enabled too on my site, and I saw in another issue that someone had problems with the combination Domain Access-Content Access. Maybe this is the problem?

I don't use Panels.

I disabled the Domain Access module, and now it works perfectly.
But the problem is that I need that module! :-(
So something goes wrong with that combination. I don't know which module should be changed to have it working.
(I'm not as experienced to write modules...)

I'm not able to install Domain Access rightnow, so anyhelp providing a patch is appreciated.

Hey everybody...had this problem and just got rid of it by turning off the module and turning it back on AND, rebuilding the Permissions each time. The regular total cache flush under Performance does NOT work, even tried doing several times in a row, which will sometimes catch things that don't clear the first time. If you don't know where to do this, run the Status Report and look half way down the page to the Node Access Permissions section. There is a 'Rebuild Permissions' link there. This function can take a long time if you have a lot of content.

I didn't disable and re-enable the module, simply rebuilding permissions (under Status Report as described by @MhueD) fixed it for me. In my case, the content was created before installing and configuring Content Access so that is likely where the root of the issue is.

Ok I have to it the panic button because today after an update my page with default content types disappeared. The content types are still in the structure menu but they don't show up in my add content menu under content where I usually see find content/add content .....

Does anybody has a clue ???

@bartus2510

Try rebuilding the admin menu
Site Configuration > Administration Tools > Rebuild

I too am having an issue with Content Access on my new project. Had no issue before. My first thought is that it may be because my site uses OG/Spaces/Features.... but I am going to try making a new page to see if before and after content access pages makes any difference.

Yeah didn't help. I tried disabling/enabling the module with content permission rebuild each time and also tried creating a new page since I installed it.

In all cases, unchecking Anonymous has no affect. All users can still see it.

@TravisJohnston

Tried it this way and this wasn't not succesfull

Thanks for the reply and the support....

Are you using spaces, og, or features by chance? I found out that this is the cause of my issue and our other developer had to do some overwrites to get it to work. If you are, I can see if I can find out what exactly needed to be done.

Aw this is interesting. So it wasn't any tweaks that he needed to do. It was just granting Content Access priority over other modules.

To do this
-Admin > Content Management > Content Type > pick the content type and choose Manage Fields > Access Control tab
- Under the Advanced section at the bottom, bump it up to 10.

Hi Travis,

I fixe my isseu by enabling the links back again in structure/menus/navigation. In a weird way they were disabled ....

still don't know whjy but users can add content back again

With kind regards
Bart

#19 is exactly what I need and it works!!! Thank you very much.

Resetting priority, this was raised in #14 for a problem that seems to be unrelated to this issue.

I had the same problem, on a site not using any other access modules. I configured permissions for a content type (disallowing view access for anonymous and authenticated roles). The message said permissions were rebuilt (see also #1507560: Permissions are not rebuilt after saving settings, but view access was still granted for a newly created node. I tried rebuilding permissions from admin/reports/status, which finished in under a second (didn't seem to do anything). I cleared caches, etc. etc.

Only after clearing caches several times and several times of rebuilding permissions from the status report did the rebuild action actually do something (batch operation), and then permissions worked as expected.

With "Chain Menu Access API" module enabled I have this problem. Disabling that module permissions work.

Running Drupal 7.15 with the same problem of Content Access not restricting access to certain content types as expected. As soon as I rebuilt node access permissions, the issue went away and access is denied as the settings reflect.

Rebuild the permissions at 'admin/reports/status' under the Node Access Permissions heading.

@MhueD. Thanks for this advice!
I had the same problem: I installed Content Access in a Drupal 7.14 website. In another Drupal 6-site it worked perfect. In this website however, it didn't. I could set every permission like it should, have made a specific "member-page", but it was visible to anonymous users as well. Now I have turned off the module and turned on again. Re-build the permissions. And now it works perfect, like it should! Great!

#19 didn't work for me... unfortunately.

Related: #1860058: Tell users to rebuild permissions when they change content-type access rules

Hi,

I'm also running a Drupal 7.18 multisite with current Domain Access 3.7.

I looked and tested a long time to find out why the Domain access node permissions (view / edit / ...) are always winning from all the permission related modules (like http://drupal.org/project/node_view_permissions and others).

The advice from #19 helped me out by using the "http://drupal.org/project/content_access" module and setting its "node grants priority" to 10
=> now I actually see using Devel (Access permissions by user) the effect I wanted

Thank you!

Guys. Just to let you know that I just had the exact same issue while test-installing the Domain Access module on top of existing site running great with Content Access module. #19 worked a charm thank you @TravisJohnston

Details and initial problem for anyone still looking into this:

1. My existing site was running great with Content Access in place - with Content Access being used to lock out ALL of my content for anonymous users (except for the login block).
2. I test installed Domain Access (to begin to add affiliated sites to the top domain) and Whoah all my previously anonymous content (like the whole site) was suddenly viewable to the whole world again.
3. Changing the "Node Grants Priority" to 10 under the Advanced tab of Access Control tab (following #19 above) immediately re-asserted anonymity to the content again.

Build here is: Drupal 7.2.1 running an Omega/Delta theme.

Q.

Chiming in to say that we have had this problem. Our setup is Drupal 7.20, Domain Access 7.x.3.9, Content Access 7.x-1.2-beta2.

Following the instructions in #19 (process outlined and instructions reiterated in #30) resolved the problems we were having, and now CA is back to working like a charm. :-)

Joining the chorus to say that #19 solves the problem! Thanks!

Added the fact that there are also 2 panels.

Hi.

Why not make "10" as the default value when we enable the option "Enable per content node access control settings"?

In my experience I had problems with cached pages when using the default value of "0" (value of "10" made it work).

In another point of view, perhaps this is a bug... Is it possible/viable to purge the caches for a node that had it's acl changed? That way the priority may be kept as "0" and nobody will see the node using the cached permission.

Regards,
Gilsberty

It seems @MhueD has the correct answer, I've tried and it works.

Thanks a lot

http://www.neyra.mx/

#19 did the trick for me. Would never have figured this out myself

#19 Worked for me, I had to rebuild permissions after, but then it worked.
Thanks!

Hi everybody, I tried #19 and It doesnt work... My problem is that I created a content type that user can create, edit, delete their own content but only view the content of other users.

For some reason(s) when I give permission to "edit own content" it seems that it doesnt work, I created a block on the user page using View to see the content a user has created, I added a Edit link to each content but when I click on this link the path is "for exemple: site.com/user#overlay=node/1/edit%3Fdestination%3Duser/2"

If someone had the same issue or know the problem, please help me out.

Thanks!

#19 also worked for me, ending hours of retrying, rebuilding, searching, reading documentation, retrying, rebuilding ...

Now I'm wondering if 10 is the value needed; or is it anything greater than the default of 0? Just wondering ...

Don't think it is really necessary, but if there are any other content access modules (custom or contrib) that may be taking precedence, you will need to increase the number. 10 seemed like a safe place to set it ;)

Thanks Travis, #19 works for me.

Proper issue status, not sure what's the status on this issue?

For me content access work perfectly, its just need to rebuild permissions or set grants priority to some higher number as per #39 comment.

Please reopen if anyone still have this issue.