I've seen closed issues about this (http://drupal.org/node/429744) for D6 but nothing for D7. I'm not really sure where to start.

I have a site that is constantly displaying the following system messages:

The content access permissions have not been properly rebuilt.
The content access permissions need to be rebuilt.

Every time I try to rebuild it fails with:

An AJAX HTTP request terminated abnormally. Debugging information follows. Path: /examplecom/batch?render=overlay&id=246&op=do StatusText: error ResponseText: ReadyState: 0

I've tried different browsers, cleared caches, etc. I even get the message with the Content Access module disabled. There's not a lot of content on the site so I doubt it's a memory issue. Can anyone give me some insight into what's going on here?

Files: 
CommentFileSizeAuthor
#15 modules_list.txt1.78 KBvideographics

Comments

hmm the permissions rebuilt is a core function, it mostly display such errors when you have a low-RAM available for PHP, try increasing it, restart apache, then rebuild access again. Also make sure no other module is causing this error (try also on fresh site), then update this issue with your results :)

Priority:Normal» Critical

Really stuck. Most roles have very little access to anything on the site and all of the access control modules are disabled. The only thing that gets anyone but an administrator access to any content is the "Bypass content access control" permission. Am I going to need to go directly to the database to fix this?

Sorry, I didn't respond to your memory suggestion. I'm at 768MB and it's still failing. There is VERY little content on this site and the number of modules isn't unusual. My fresh sites on this server don't have this issue but I still have a problem with this one. What other module might be affecting this? I've disabled ACL and Content Access.

I'll continue trying it with increasing the memory limit but I have similar sites using 256MB without these problems.

It's still failing with 1024MB.

Status:Active» Closed (works as designed)

Got it!!! I tracked it down to an Organic Groups permission module. Thanks for your help! Sorry to trouble you.

Status:Closed (works as designed)» Active

It's back. Rebuilt permissions once without a problem but then I reenabled Content Access and the problem is back. Still struggling...

Well, different access modules can *sometimes* be collapsed with each other, anyhow as I said there is nothing to do with Content Access since core do this, unless you give me a how-to reproduce this, so then I can be sure it's this module's problem. Otherwise, your problem is not clear at all.

I understand the rebuilding permissions is handled by core, but isn't it still possible for other modules to create a situation that would cause core to have a problem like this?

While I can't say for sure that Content Access is responsible for the problems, I can say that it's involved enough to keep core from doing it's job when it's enabled. I CAN rebuild my permissions with the module disabled and once I enable the Content Access module I can no longer rebuild permissions.

Even if it's not the Content Access module itself, it seems like it's involved in some way.

Whatever it is, I think it's possible that I have some type of data corruption but I can't be sure of the source or how to address it. Any insight anyone has on this would be most appreciated.

Would it be too risky to try to just clear out any database tables related to permissions so I could "start from scratch"? I have no critical permissions related setups on this site yet.

You didn't provide clear steps on how to reproduce this "bug". Unless I can't replicate it on my dev machine, I can't fix it. That's said, I need you to replicate it on clean site, then write the series of steps you made to get to that situation.

Category:bug» feature

I'm sorry for not being able to present you with a reproducible bug. Even though I can't be sure one way or another, my suspicion now is that this may NOT be reproducible from a clean install in which case I'll change this to a support request. What I can verify is that enabling the Content Access module prevents ME from rebuilding permissions on this one particular site. For one reason or another, when I enable the Content Access module, I cannot rebuild permissions and when I disable it, I can rebuild permissions without a problem.

I brought up this issue because I need some perspective on my situation -- regardless of the cause -- and would really appreciate some assistance digging myself out. Even if it's not considered a bug, I thought this would still be of interest here and, in the best case, I can imagine there being some interest in figuring out what kind of corruption (if that's what it is) would cause this module to affect the core rebuilding capability in this way.

Category:feature» support

First I want you to list what are the enabled modules on your site. Second try:
drush ws
in terminal (note: you need drush module), to see what's going on under the hood.

Hopefully with those information we can figure out the problem.

Note: Also, try Content Access dev version.

Status:Active» Closed (cannot reproduce)

StatusFileSize
new1.78 KB

Module list attached.

drush ws get me:

119347  30/Nov 10:55  notice  php  Notice: Undefined offset: 0 in views_handler_field_field->option_definition() (line 293 of /example.com/sites/all/modules/views/modules/field/views_handle
119346  30/Nov 10:55  notice  php  Notice: Undefined offset: 0 in views_handler_field_field->option_definition() (line 293 of /example.com/sites/all/modules/views/modules/field/views_handle
119345  30/Nov 10:55  notice  php  Notice: Undefined index: commerce_line_item in views_handler_field_field->access() (line 78 of /example.com/sites/all/modules/views/modules/field/views_ha
119344  30/Nov 10:55  notice  php  Notice: Undefined index:  in views_handler_field_field->access() (line 78 of /example.com/sites/all/modules/views/modules/field/views_handler_field_field.
119343  30/Nov 10:55  notice  php  Notice: Undefined index: reverse_field_order_reference_node in views_handler_field_field->get_base_table() (line 97 of /example.com/sites/all/modules/view
119342  30/Nov 10:55  notice  php  Notice: Undefined index:  in views_handler_field_field->access() (line 78 of /example.com/sites/all/modules/views/modules/field/views_handler_field_field.
119341  30/Nov 10:55  notice  php  Notice: Undefined index: reverse_field_order_reference_node in views_handler_field_field->get_base_table() (line 97 of /example.com/sites/all/modules/view

So it seems "Undefined index: in views_handler_field_field->access()" is of most interest all but I have been unable to find any guidance in addressing Undefined index issues. The fact remains that I can rebuild permissions without a problem until I enable the Content Access module. If you can't help me with this, could you at least point me in the right direction. I'm feeling really stuck.

...just tried the current dev version with no joy.

I tried to guess what the problem might be, but I couldn't. The log of drush ws you pasted is irrelevant to this problem (other bugs, notices). I have to keep this issue closed unless you provided steps on how to reproduce (my best guess for your problem is an error in config).

P.S. Uninstalling module doesn't remove the files, don't remove things from your reply, as they might be useful for someone else ;)

good_man, please do not confuse this SUPPORT REQUEST with a bug report. I do not expect this problem is reproducible from a clean install. I just need help making sense of this mess I'm in. Closing an unresolved support request seems to me to be nonsensical. I think it only makes sense to close this issue when I'm able to figure out why I can't rebuild permissions with the Content Access module enabled. With that said, I'm not suggesting there is any problem with this module that would necessarily require a change to the code. I just need some help with my particular implementation. If I can't resolve this, I'm seriously faced with completely rebuilding this fairly complex site from scratch just to be able to manage permissions on it. It's easily a month of work involved.

I'm hoping someone can provide some insight so I can figure out what kind of configuration error is involved or which tables to go clear out to get this working again. The reason I'm in this queue is that the Content Access module is the closest piece of code I can confirm is related to this problem. I'm NOT saying the code is responsible. I'm just hoping you have more insight on this that someone reading the issue queue for the Unicorn Ponies Theme (http://drupal.org/project/unicornponies).

Any insight into what config might be affecting this or which tables are involved would be appreciated.

BTW, if a config issue on it's own is able to kill this module and we can identify the problem, it might be worth investigating whether it would be worthwhile to include some error checking in the code to prevent this from being a problem for others in the future. Essential modules like this need to be as robust as possible. In this case, this does become relevant to the code of this module. I can confirm, one way or another, for my implementation, something related to this module is preventing me from rebuilding permissions on my site.

BTW, I removed my comment about the removed files because it was completely irrelevant to the thread and something that was working as it should.

My friend, I know that this is a real bug, but problem is, I can't figure out how to find it. That's why I needed help from you, but seems you are not able to figure out how it did happen too.

I want you first to take backup, then check {content_access} table and {node_access} table. If you really want to wipe out all the access rules, then empty those tables. It's a risky operation, that's why you should have backup + do it on a mirror dev of the site not production one (note: uninstalling content access will remove data from {content_access} table). Then try to re-activate the module, rebuild permissions and check if it works. I doubt this will work, but this is as far as I can get from your comments. I'm not responsible for anything happen when doing this, if you can't do it, try looking for some consultation.

Thanks for sticking with me on this. I know full well not to do any of this on a production site. I also know that I'm ultimately the only one responsible for any issues with my site. I'm just looking for ideas to get this working.

I have cleared the content_access table and reactivating the module and it had no effect. The problem persists.

Is the node_access table the only other one involved here? I'll try clearing the node_access table just to see what happens... I'll report back.

At this point, I'm actually preparing for the possibility that I may need to rebuild the site from scratch. (It's currently the only sure path to being able to launch this site.) If I do move ahead and if your hunch is that this is indeed a bug, I'll still following through with trying out any ideas anyone has for resolving this. We do need to the bottom of this. It'd be best not to have such an important function in such a fragile state.

Hi -- I had what I thoug was a similar problem this past weekend and was able to solve it. Perhaps thei can help you. Please have a read of this node anda those I referenced. In the nd my problem was one corrupt node in my db that views help me detect and drop. Then it all worked like a champ.

http://drupal.org/node/1360034

Good Luck!

Issue summary:View changes

Sorry for bringing this old issue up, but want to leave a hint for anyone with a similar issue and similar difficulty finding it: it's in many cases some "bad node" (missing content type, non-loading author object etc.).

A very simple way to see which node is causing this: open modules/node/node.module, look up function node_access_rebuild there, and insert a debug instruction like this at the start of its foreach loop:

echo("going to process node $nid ...\n");

Then run the "rebuild permissions" task on the command line with drush php-eval 'node_access_rebuild();' and look up the last printed node ID before it crashes. Fix or delete this node and repeat the drush step until the task runs through. Don't forget to clean up node.module again.