Access denied on new content

yes, it likely does. i can't say for sure since i can't see your site. please try latest og - 5.5

Still getting error:
Access denied. You may need to login below or register to access this page.

With og - 5.5 and (and domain module but disabled OG Audience 5.x-1.1 - mentioning it if it is relevant).
I looks like if content is not belongs to any group, it shows this error, eventhough with the following settings,

Access control :
Enabled

Private Groups:
Group administrator chooses whether her group homepage and audience are private or not. Defaults to public.

Visibility of posts:
Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Public.

When posting a node, Under "Audience" setting
Show this post to everyone, or only to subscribers of the groups checked above. Posts without any groups are always Public.

Even for content in Omitted content types, the access denied still exist.
Please don't mind I reactivate the status ...

I found I had to rebuild the access tables. See here:

http://drupal.org/node/213040

I had the same problem here. 5.6 installed, installed OG 5.50. After disabling the module, new content would not show.

I looked around and found that NEW nodes were not being added to the node_access table. I couldn't find exactly what had happened, so essentially I restored a database backup I made prior to installing OG.

Will wait for a new version, when this problem has been fully identified and fixed.

Happy to provide more information if you guys need it.

thanks !

Can confirm that this happened to one of our sites as well (no node_access records for new nodes, causing access denied everywhere), and rebuilding the node_access table (in admin/content/node-settings) fixed the problem. It was interesting to note that editing the node and re-submitting it seemed to fill the node_access table properly.

This was with 5.x-4.0, and no code/db changes in recent memory, so very bizarre. We'll keep an eye on it.

I'm seeing a similar issue with one of my sites.

We noticed that whenever we edited a page (that was not associated with a group) it would give an "Access Denied" to anonymous users.

Rebuilding node_access table fixes the problem until the page is edited again.

I did a quick test to show how the rows in the node_access table changed before and after edit (see attached).

Ok, well since this is obviously a problem w/ more than one site, bumping to a bug, and a critical one at that.

FWIW, I'm running OG 5.5 and am seeing the behavior as reported above.

Fixing version, based on kmillecam's comments.

i need more information to debug this. are these all og upgrades, or some virgin sites. some people say that new nodes have denied access, some people imply it is existing nodes.

@webchick - if you were running 5.4.0 you were missing some significant bug fixes.

for those having troubles, please try to rebuild node permissions at /admin/content/node-settings. make sure you do not get a timeout error, which can happen on a large site. core has fixed that issue for D6.

if you still have troubles, plese post here exactly what you expect to happen and what is actually happenning. also explicitly confirm that you are not running any other node access modules nor any og helper modules. if you are, disable those and rebuild node access permissions again.

Moshe,

My installation was a virgin one, 5.50.

best
Leo

My problem seemed to be when nodes were updated but, unfortunately, I can't reproduce the issue (with new nodes or edits) today.

any more info?

Hi, Moshe

I had this problem too. I'm using 5.6. I installed Organic Groups last Sunday and then decided to not use it and unchecked it from the modules admin page. After that, almost all the content from my website started being "access denied" to authenticated users and to anonymous users. It only showed for the admin. There was only one kind of content that was still working (created with CCK) - I believe I didn't give access to any groups to it. All the new content I created after that, even the ones using the default content types, weren't accessible to anyone. I just found this forum, went there, reactivated OG, clicked on the enable button and everything worked again. Then I clicked on the disable button, desactived the module and everything seems to be fine. I also don't have the option to allow access to OG in my access control panel. The only option I have there is "administer organic groups".

I don't know what other kind of information would help you. Please let me know if there is anything I can tell you that will be valuable.

I also would appreciate if you could let me know if what I did is fine to have everything working. I'm not sure I should uninstall the module and if I should, I'm not sure how to do it.

Patricia

This has come up on another client site. No records inserted into the node_access table. Again, rebuilding the node access table fixes it, but this time the behaviour comes back on the very next node.

They're using 7.3, which I know is not the latest blah, blah. But honestly, this bug has reared its ugly head in many different versions of OG and various configurations, and it's worth figuring out what the heck is causing it.

Assigning to myself to try and get to the bottom of it.

Just as an update on how it happens, not quite there yet on the why...

The setup we have here is absolutely ridiculously complicated, with Workflow, Workflow Access, OG Actions, OG Access, Content Access, blah blah. When this error is getting triggered for us is when changing a workflow state from "Editorial Review" to "Published" which a) removes it from all groups, b) Publishes it, and c) adds it to the "Public" group. When all is said and done, the node_access table ends up with no records for the node (even though og_ancestry is correct), and people who ought to have access are getting "Access denied" as a result.

Obviously, it's not the problem of OG to deal with my cilent's complicated setup. ;) But what's interesting is as I'm stepping through, I've discovered that it's doing all of /that/ stuff correctly. It makes it through all of the hook_nodeapi() calls for the node whose workflow transition is being changed and everything looks good: node_access records are in place, I can open a second browser and view the node as an authenticated user, etc.

Where everything goes horribly wrong is immediately after the nodeapi calls, node_save is calling http://api.drupal.org/api/function/node_access_acquire_grants/5. The first thing that node_access_acquire_grants does is call:

For whatever reason, this grants array is coming back with /only/ content_access's grant record (which is ignored since content_access is just saying view => 0 which is already implicit), not OG's. And so when http://api.drupal.org/api/function/node_access_write_grants/5 does its thing, it happily deletes all traces of records in the node_access table that refer to that node, and then loops through the $grants array and says "Nothing to do here!" and we end up in a pretty big pickle.

Still looking into it to figure out why this happens...

Incidentally, $node->og_groups is empty, which causes og_node_access_records() to think it can ignore the node.

I got real excited thinking #362493: og_nodeapi presave might filter out groups. was maybe the solution to my woes (since the node _is_ being saved multiple times [actually, three: one to publish it, once to assign it to a group, and once to save the workflow transition; silly workflow 5.x-1.x module]) but it didn't seem to make a difference.

Ok. The $node->og_groups = array() thing is happening because somewhere deep in the bowels of the workflow/actions system, the node no longer gets passed in by reference, so it is not updated with the changes that happened during the action_og_add_group() action. It's a mystery to me why this ever works, but it doesn't appear to be an OG bug in my case. Unassigning self, will go toil over in the workflow queue.

Just in case someone (such as my future self ;)) is curious on why this happened, in /my/ case, it was due to the following:

As mentioned before, when the node transitioned from the "Editing" workflow state to the "Published" workflow state, the following things would happen:

1. (Action) Remove node from all groups.
2. (Action) Add node to the "Public" group. (triggers a node_save())
3. (Action) Publish the node (triggers another node_save())
4. (Node) Finish saving the node. (triggers yet another node_save())

Yes that's three, count 'em, three node_save()s. :P I assume this got better in the 5.x-2.x version of Actions/Workflow (we're using Actions 5.x-1.0 and Workflow 5.x-1.2). Nonetheless...

When doing the node_save() in step 2, the node has no og_group assignments. This is fine, and by design, since the action before it said we didn't want any.

When doing the node_save() in step 3, the node has the proper og_group assignment and saves to the database. All is well in node_access table land... UNTIL!

We hit the final node_save() in step 4, which still has a copy of the node from step 2. The node that was awesome and had the right stuff completely vanished between steps 2 and 3, basically because its scope was local only the to the actions_do() function. Once we head back up the tree to workflow_workflow, the $node variable in its scope only knows of the old node that didn't have any group assignments.

So my workaround is simply to remove the "Publish node" action at the end, which we don't need anyway since this checkbox defaults to true and OG is handling the access control. I will save figuring out why the simple act of adding this extra action destroys my database for another day. ;)

Oh. The summary for those of you having this problem: check to see if something is inadvertently unsetting $node->og_groups (place some debugging code in og_access_node_grants() in og_access.module).

If this happens, OG won't respond to the question "does anyone want to jump in here and do something with access control?" asked by node_access_acquire_grants() and then node_access_write_grants() will think it's doing you a big favour by deleting all of the node's records in the node_access table.

When this happens, the node will be unassigned to any group, and assuming you default your content to private, it will only be visible by someone with "administer nodes" permissions.

Happy hunting! :P