"You are not authorized to access this page" error when editing roles for a group

I've getting this error, and the error message. It appears on the group's "OG permissions" and "OG roles" page.

Additionally, on the global config for the content type, OG Permissions shows a page with no checkboxes. When I refresh, I get
Warning: Invalid argument supplied for foreach() in element_children() (line 6370 of includes/common.inc).

Access is also denied to "Add people".

A bit of troubleshooting, and it looks like this happens when there's no post content associated with a group.

- Somehow the role/permissions map is getting deleted, and not re-created, if you ever remove all the post-content from the group.
- I think subgroups is unrelated, this was happening to me with regular group content as well.

So a workaround is simply to create group post content right away, and always leave just one...

Hi Stella!
I can't seem to reproduce it on a clean installation, any chance you can try to reproduce and write the steps or attach a db dump?

Any update on this issue...have the same problem...

i can provide you with a db dump if you want

Also experiencing this issue, and even after creating content for group I still get access error. FYI: I tried accessing group pages as both admin and as manager (non-admin group creator) and neither have access.

See #4

Continuing the process from http://drupal.org/node/1880480, I'm now having the same issue as this.
Same issue with Group or Subgroup

Example: OG Node - Division Group Permissions (Subgroup of Groups):

•Warning: Invalid argument supplied for foreach() in element_children() (line 6370 of /var/www/vincent7/includes/common.inc).

I get no check boxes in the permissions to select in the table and I get Access denied (even for user 1) when I try and do anything under the Group tab (Add people, People, Permissions.....)

Seems the og_role and og_role_permissions tables are empty after the migrate. I have tried to copy the permissions over from a backup, but no luck. If I rebuild permissions, it just wipes out the 2 tables again.

update: I did a fresh install of drupal and og, making sure to make one bit of content for the group and it all works fine now.

@Amitaibu It seems related to my comment about not having any content.

I had the same problem. After a few hours of debugging, I have found out that it was a side effect of changing the machine name of the group type.

As I first created the group type I have made a typo by writing the machine name. As I noticed my typo, I have corrected the machine name. However, it was not updated in the table 'og_role', column 'group_bundle'.

I have updated it manually on phpmyadmin, and now it works as expected.

#14 did it for me!

On two different sites I had changed the machine name and the table 'og_role', column 'group_bundle' was not updated. Manual correction in the database and we're cooking with gas.

@pc-wurm THANK YOU!!!

I have created a patch that adds the og_roles for a new machine name and removes the old one.

The logic is there. I am not sure if this is where it is best put or if the $info->old_type should be sent to og_ui_node_type_save or is there should be a new function created in og.module called og_change_group_bundle.

This is a little complicated because generally the changing of the og_role is set on the adding and deleting of the field and not on the insert or update of the content type.

circuscowboy

retesting on dev

#15: update-og-roles-when-updating-content-type-machine-name-1868428-15.patch queued for re-testing.

If we could get one of the 10 people following this to test my patch it would be good - I don't really want to my work fall into the abyss of overlooked. It is an edge case but still a bug none the less. This is me flapping my arms saying look over here - got a bug fix for you.

Thanks

circuscowboy

#15: update-og-roles-when-updating-content-type-machine-name-1868428-15.patch queued for re-testing.

patch #15 applied successfully it said but still the same "You are not authorized to access this page" even after update.php, refresh caches and rebuilding access permissions.

On thing that might be of importance, is that the groups audience field in my group type (which is 'Region') is not using the regular og_group_ref field but another entity reference field which also uses the OG widget and using the OG mode entity selection, so it should work the same; everything the same only field name different. the group type 'Region' does show up in the OG role settings edit list but as mentioned gives access denied.

My issue is resolved. As mentioned by pc-wurm in #13, I had change the machine name of the content type. Very simple manual change of the rows in the database fixed it. Thank you @pc-wurm!

Oh my, took me some time to go back to this issue -- sorry.

#15 looks ok -- but I'd be happy to see it come with a simpleTest

I will look into writing some tests. Simpletests are something I have wanted to do for a while but never done. Any direction would be helpful.

> Any direction would be helpful.

Lots of examples in og.test ;)

Thanks to @pc-wurm and #13.
That was my issue!

Thanks, #13. That did it!