Debuging OG access field

Question

I have few roles in OG groups: Visitor, Reviewer, Member, ...

Visitor and Reviewer are added roles with (at the moment) exactly the same settings. Unfortunately somehow Visitor is inheriting Member's access rights while Reviewer is not.

I checked everything and all looks fine. I tried hacking OG code (I switched off the default role inheritance), checked og_role_permission table and all looks fine. But still whenever I give some rights to the Member role, Visitor user is somehow inheriting them while Reviewer is not.

My website is making use of OG roles everywhere. I have context, rules, custom code depending on it. And while everything works fine, field_access is behaving strange.

Do you guys have any idea how can I go on with debugging this issue? Is there a place in node_access module where I could put some debug code informing me what is going on?

UPDATE

I switched off all the custom code, changed drupal core to older version, made sure that access settings for Visitor OG role are exactly the same as Reviewer's.

I rebuilded cache, rebuilded access rights, changed browsers, went through code in OG and data stored in the db.

Still users with Visitor OG-role inherit rights from Member OG-role, while Reviewer does not. This bug is killing me.

Answer 1

Unfortunately I have to surrender. There is a bug somewhere in the og module but I can not track it down. What happens is that the default group membership role can not be changed. Changing the definition of OG_AUTHENTICATED_ROLE in the og.module does nothing. Because of that all the access rights given to the "member" role are being inherited by all the other roles and so they can not be weaker.

My solution will have to be creation of new members role - "full_member" where I will be able to define roles of that member. I will also remove all permissions from the "member" role. The problem is that I will have to redo all the rules, contexts, pages, blocks, custom code and so on. Few days of boring work and debugging.

Answer 2

Unfortunately no walk around works in here.

OG has a major bug for subgroups. Basically permissions for the subgroups (including field access rights) get inherited.

In other words if B is a subgroup of A and I am a member of both, then in A I have access rights from A while in B I have a sum of access rights from A and B.

This issue can be addressed by a simple og.module hack

function og_user_access_entity($perm, $entity_type, $entity, $account = NULL, $strict = TRUE) {
// ...
    else {
      // An entity can be a group and group content in the same time. The group
      // didn't return TRUE, but the user still might have access to the
      // permission in group content context.
      $result = FALSE;
    }
//...
}

What happens here is that if OG module can't find specific access rights for a group that is also a content (is a subgroup), he will treat it as a standard group content and will look for access rights in the parent group. We can fix it by simply returning FALSE.

    else {
      // HACK - NO GROUP INHERITANCE
      return = FALSE;
    }

This solution seems to me as much more reasonable and consistent. Note that the access rights inheritance is going only one level down and only if you are a member of both, parent and son groups, it also overrides your field access rights that should have nothing to do with a parent group.