The attached patch fixes some random behaviour when submitting content_access-related forms.

This was messing up permissions for anonymous users (rid 1) because the arrays in question had the form "rid1 => 1; rid2 => 1" instead of "0 => rid1; 1 => rid2" (i.e., array_keys of the former).

I briefly tried the latest -dev, but this behaviour still seemed to be there.

Comments

fischerj’s picture

patch works fine. Thx!

jwgreen1974’s picture

In my case I came across this on a new site I was building, and the module worked on one test site and not the other. The difference was that on the one that was not working, I had created a role for site administrators and put the super-admin in it, which was also the account that I was using to work on the site. When I did this on the site that did not have this problem, the problem showed up there as well. Both sites were bare-bones with no other modules installed but this and the ACL module. When I deleted the site admin role, going back and re-editing the permissions in the nodes that had problems fixed the issue.

picapaoo’s picture

Category: bug » support

Hi everybody,
i`d like to apply this patch too but I´m not a programmer.
What do I need to to?


Replace this code in the content_access.admin.inc file:


foreach (_content_access_get_operations() as $op) {
// Set the settings so that further calls will return this settings.
$settings[$op] = array_filter($form_state['values'][$op]);
}
// Save per-node settings.
content_access_save_per_node_settings($node, $settings);

if (module_exists('acl')) {
foreach (array('view', 'update', 'delete') as $op) {
acl_save_form($form_state['values']['acl'][$op]);
}
}

by this code (patch):
@@ -68,7 +68,7 @@
$node = $form_state['node'];
foreach (_content_access_get_operations() as $op) {
// Set the settings so that further calls will return this settings.
- $settings[$op] = array_filter($form_state['values'][$op]);
+ $settings[$op] = array_keys(array_filter($form_state['values'][$op]));
}
// Save per-node settings.
content_access_save_per_node_settings($node, $settings);
@@ -156,7 +156,7 @@
foreach (content_access_available_settings() as $setting) {
unset($settings[$setting][$form_state['type']]);
if (isset($form_state['values'][$setting])) {
- $settings[$setting][$form_state['type']] = is_array($form_state['values'][$setting]) ? array_filter($form_state['values'][$setting]) : $form_state['values'][$setting];
+ $settings[$setting][$form_state['type']] = is_array($form_state['values'][$setting]) ? array_keys(array_filter($form_state['values'][$setting])) : $form_state['values'][$setting];
}
}
content_access_set_settings($settings);

Please help!

Thanks,
Chris

grobemo’s picture

I had the same problem on a new site: I was unable to disable access to a "Staff Page" node type for anonymous users.

This patch solved the problem for me (using Content Access 6.x-1.0 on Drupal 6.10).

Thanks, avf!

xhochy’s picture

Category: support » bug

Flagged it as a bug report since this is a bug and not a request for support.

capmex’s picture

Tested patch, it fixed the issue.

pepó’s picture

Patch works.

xhochy’s picture

Status: Needs review » Reviewed & tested by the community
leon85321’s picture

NICE FIX!!! avf

Thank you very much!!

Leon

fago’s picture

Status: Reviewed & tested by the community » Fixed

hm, I'm not totally sure what's the problem that got introduced with drupal 6.10, but indeed some tests failed and your patch fixed that. So I've added your fix to the rules integration too and committed it. thanks!

fago’s picture

Please test the next generated dev snapshot.

tryitonce’s picture

Hi Chris,

did you work it out or are you still waiting for the answer?

jvieille’s picture

I tried today's dev. It doesn't work.
I am still unable to disable "View any content" and "View own content" for anonymous user

picapaoo’s picture

Hi tryitonce,

no i didn`t work it out yet. I`ve been waiting for the answer for a while. Then i switched to nodeaccess -that one works fine:-)

That doesn`t mean I`m not interested getting an answer anymore.
It´s just a matter of time having the same patch problem again with some other module...
So what do i need to do to use this patch (or other)?
Replace the ancient code by the patch code in the file? I know, this question sounds silly for some expert, but as i said: I´m no programmer!!
I`ve only got some basic skills in action-script1&2 programming, that`s it...

Thx in advance!

Chris

duozersk’s picture

Status: Fixed » Active

Just checked the latest dev available; it looks like the patch from this issue wasn't applied - just looked on the strings this patch changes and they were not changed.

tryitonce’s picture

Hi Chris,

You need to open the file "content_access.admin.inc" with a suitable editor - I use PSPad - http://www.pspad.com/.

The patch is for the replacement of two lines of code:
1. line

  1. You then just look for the line number 68 which should be $node = $form_state['node'];
  2. now you follow the code until you get to the line $settings[$op] = array_filter($form_state['values'][$op]);
  3. this line you have to replace with $settings[$op] = array_keys(array_filter($form_state['values'][$op]));.
  4. 1 line of the patching is done.

2. line

  1. Now you scroll done to line number 156 which should be content_access_save_per_node_settings($node, $settings);
  2. again follow the code until you get to the line $settings[$setting][$form_state['type']] = is_array($form_state['values'][$setting]) ? array_filter($form_state['values'][$setting]) : $form_state['values'][$setting];
  3. this line you have to replace with $settings[$setting][$form_state['type']] = is_array($form_state['values'][$setting]) ? array_keys(array_filter($form_state['values'][$setting])) : $form_state['values'][$setting];

That is it. Now you have to make sure that the file is saved. It might take a few seconds to go through - a little longer if you are not working on your home local machine. You might need to clear your cache and make sure Drupal is running in development mode - with cache disabled - or clear the cache in Drupal as well.

Now you should have fixed the problem. Quite simple in a way, but not so easy the first time - as many of the experts assume we know all these simple mechanics of "brick layiing". I am not an expert and can very well understand how you feel. I hope it works and do ask the experts "silly" questions - well there are no silly questions - only silly or sometimes arrogant answers.

I guess patches are shown to include relevant code of the routine around the patch - so the expert can see exactly what the patch will do and whether it will work. So, fair enough.

I hope it helps and works for you. Good luck

CC

By the way - do report back how you solved your problem and do write how you did it - add file names and links to where you found help, files, etc. - lots of people joining Drupal will be grateful - for a simple, "start-with-the-basics"-approach.

TSE’s picture

Hi,

i had to use this patch since it's not in the latest dev version: 6.x-1.x-dev from 2009-Mar-16

Worked fine, Problem solved ;)

ThX TSE

akalsey’s picture

Title: Random behaviour when submitting content_access forms » Permissions for anonymous user not saved
Status: Active » Reviewed & tested by the community

Patch tested against Mar 15 dev snapshot and 1.0 release. It applies perfectly and fixes the issue.

Changing the title to be more descriptive of the issue (to help other people find the issue and patch).

fago’s picture

Version: 6.x-1.0 » 6.x-1.x-dev
Status: Reviewed & tested by the community » Fixed

grml, somehow the changes in .admin.inc were not committed. I've done it now, sry.
Again please test the next devel snapshot.

wdevn’s picture

This patch really works!

Thanks a lot!

duozersk’s picture

fago,

It looks like a major functionality fix for the CA and its Rules integration... so maybe it will be appropriate to release the 1.1 version?

swordedge’s picture

Patch works... silly way to apply it (manual editing of said file)
and when I finally disabled Anonymous from viewing my members only page, it said

Access denied
You are not authorized to access this page.

It is also a menu item and... disappeared from the menu... yay! Log in and it reappears.

Can I edit that access denied page message?

Over all, took all da?? day to find and configure a members only section. Way too long IMHO

Now to test autologout... 23 days logged in is idiocy

fago’s picture

>It looks like a major functionality fix for the CA and its Rules integration... so maybe it will be appropriate to release the 1.1 version?

I agree, I just wanted to be sure it works.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

CarbonPig’s picture

subscribe

danny_joris’s picture

Version: 6.x-1.x-dev » 6.x-1.2
Status: Closed (fixed) » Active
StatusFileSize
new17 KB
new23.77 KB

I'm very sorry to open this after such a long time. But I still have this issue.

When I disable anonymous users to view a certain content type, this content type will still be viewable for anonymous users. According to 'Devel Node access by User' the permission is granted by Node Access permission. I have two screenshots in the attachment.
But disabling node access for anonymous users in permissions, makes it that I can't enable access for anonymous users using Content Access...

Thanks in advance,
Danny

tryitonce’s picture

You need to enable
node module - access content for anonymous users.

Otherwise they will not see anything.

Then you need to go into each Content Type and change the settings to what you require.

The problem comes if you grant node module - access content for anonymous users and later add the Content Access Module. In this case all Content Types will allow anonymous users to access all nodes. If you now load Content Access Module this setting remains and you have to visit each Content Type to change the settings.

Just as a note - under

content_access module
grant content access	
grant own content access

you should check only administrator - not other user roles that should not have access to the admin. of the modules.

I hope this helps ... good luck ....

danny_joris’s picture

Hi tryitonce, thanks for you help, but I'm afraid that is what I already did. (Or maybe I'm reading your instructions wrong?)

1) I enabled anonymous permission for node module - access content and added the content access module later. Then I disabled access for anonymous users on on a specific node type. (first attachment of my previous post). Anonymous users are still able to see the node type. Also when I disable access for an authenticated user, this authenticated user will still be able to see the node.

2) something else on a side note: What I initially am trying to achieve is to disable access to a full page of a content type, but still to show this content type in a view. The reason for this is that I want to show content in a view, but I don't want their un-themed full nodes floating around. Nobody is ever going to find them, but I don't like the idea that they are still accessible for anonymous users. In the past I tried this method, and I will use it again if I don't find an alternative. The downside of this method is explained by someone else in that thread: that in redirects instead of giving a 'page not found' or a 'no permissions' error, which is not good for SEO.

My question is: if this module is able to deny access to a content type, will this module allow this content still be able to be shown in a view? I tried the nodeaccess module and it does deny access to anonymous users, but this content won't be shown in my views anymore.
I would like to make a comparison with published nodes. Anonymous users don't have access to unpublished nodes, but you can set up a view where you are able to show all unpublished nodes to anonymous users.

Thanks again for your feedback.

tryitonce’s picture

Danny,

I think you are trying to make a contradiction to work.

If you want to block a node it should not show up at all - not in views, as a teaser or so on for that role.

You could try to work with unpublished nodes.

In views you can include unpublished views to make them show up. This way user will not get the unpublished node - but should see it in views.

Another option is using CCK - with the cck access module you can allow users to see fields related to their role. So, anony. can see say basic fields, while auth. members can see those plus 3 (any number) more and premium members can see the whole story.

I have used unpublished nodes to create a database for certain information that is then displayed in a Views table - without a link to the node of course.

I hope this helps a bit - good luck .....

danny_joris’s picture

I did that in my first websites, until I saw that it confused my clients. They didn't accept it, which is normal.

Another downside to that is that you can never really unpublish such a node.

So I know now it is not possible, but having a functionality to overwrite this node access for views would not be unrealistic in my eyes.

Thanks for your thoughts on this

salvis’s picture

I haven't really digested #27 through #30, but if you're still wondering why Anonymous can view the node, then post a screenshot of the other DNA block.

andread’s picture

I had some problems with this module. I would say this post have help me a lot: http://www.zivtech.com/blog/drupal-node-access-explained-0

I have tried some different access modules before.
But I thought Content Access will be suitable for my needs.
I needed to rebuild my permissions, (You can find this option at admin/content/node-settings which is the 'Post Settings' configuration screen.) now it is working correct.
(Hope it helps someone in the future.)

Thanks for this great module. Just what I needed!!
AndreaD

fago’s picture

Status: Active » Closed (fixed)

Please don't make use of this issue in order to post support questions. Open separate issues.
If there is still a problem related to the original issue, please re-open a new one as this issue is messed up.

anewbie’s picture

This one(#32) works for me. Just rebuild the permission, simple enough. Thanks.