Posted by Josh Waihi on July 23, 2009 at 12:55am
| Project: | OG User Roles |
| Version: | 6.x-1.5 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Issue Summary
queries are still trying to use og_ancestry.is_public but is doesn't exist anymore:
<?php
// Migrate the is_public column from og_ancestry to a new og_nid table. Denormalizing.
function og_update_6203() {
$ret = array();
if (module_exists('og_access')) {
// Do nothing. An og_access update handles this.
}
else {
db_drop_field($ret, 'og_ancestry', 'is_public');
og_ancestry_dedupe($ret);
}
return $ret;
}
?>
Comments
#1
here is a patch that replaces all the instances of is_public. Please review that I'm doing the right thing here, I'm not sure, but I think its in the right direction.
#2
patch is working for me.
#3
Seems to be working for me too. Thanks for posting the patch
#4
any chance this could go into the dev version so I can fix the site without applying patch? foolishly applied upgrade to live site having not noticed this error on testing
#5
or could anyone post a zip file with the module with the patch applied? would be very grateful...
#6
Patched module attached @tallsimon.
For info, there's a wealth of info in applying patches at http://drupal.org/patch/apply
#7
thank you!
#8
patch is working for me too.
#9
Patch works for me with og-6.x-2.0 and og_user_roles-6.x-1.5
#10
I'm curious, we are struggling with access denied issues for users with configure roles. Did you have to do anything else aside from applying this patch?
#11
I'm struggling with the same thing.
#12
Phew... I've determined what many others before me have. It's that the og_user_roles module uses the core user_access function to grant permission to perform actions. From the prospective of many of us who have deployed the module, this causes an unexpected results when trying to use some of the features we expect. Namely the ability for roles/permissions to be group specific.
Here's my solution. In both the 6.x-4.0 and 6.x-1.5 versions, in the og_users_roles.module I modified the function calls to user_access to my own. I am NOT recommending this as a solution ... it's how it's going to work for me. My hope is that the 6.x-4.0 maintainer is able to achieve their long term goal.
Cheers all
-S
#13
Patch works for me too, with og-6.x-2.0 and og_user_roles-6.x-1.5