queries are still trying to use og_ancestry.is_public but is doesn't exist anymore:

// 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;
}
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Josh Waihi’s picture

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.

Josh Waihi’s picture

Status: Active » Reviewed & tested by the community

patch is working for me.

snorkers’s picture

Seems to be working for me too. Thanks for posting the patch

tallsimon’s picture

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

tallsimon’s picture

or could anyone post a zip file with the module with the patch applied? would be very grateful...

snorkers’s picture

FileSize
37.25 KB

Patched module attached @tallsimon.

For info, there's a wealth of info in applying patches at http://drupal.org/patch/apply

tallsimon’s picture

thank you!

ginc’s picture

patch is working for me too.

nemchenk’s picture

Patch works for me with og-6.x-2.0 and og_user_roles-6.x-1.5

ScottBaetz’s picture

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?

gettysburger’s picture

I'm struggling with the same thing.

ScottBaetz’s picture

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

kasiawaka’s picture

Patch works for me too, with og-6.x-2.0 and og_user_roles-6.x-1.5