Creating node that is group and group content does not work with the og field access module: 'bug' or 'works as designed'?

Can you summarize the problem and steps to reproduce, it's hard to follow the long issue description

I am able to reproduce, but can't find the fix for it...

Really, it's only the two of us having this issue... hard to belive.

I've come across the same problem today. Have we got any further on coming up with a fix?

I have the same problem.... any idea?

I have this same issue. Bravo to osmanedosbatuque for your tenacity. Any solutions yet?

I'm running into something similar.

I have a content type that can be a Group and Group Content. I don't get any errors but, enabling OG field access causes fields to not be saved the first time around. I have to save it once then go back and repopulate the fields. Disabling OG Field access makes everything work just fine.

BTW. This is not the case with a Group only content type.

I'll have a lock on this tomorrow.

A couple of questions:
1. under admin/config/group/settings does the "Group manager full permissions" option is checked?
2. If unchecked - please check the Organic groups field access in the group. Does the View/edit Body field is checked?

I am facing same issue: https://drupal.org/node/2175183
@@ Patribu: are you able to find some alternative for this issue except for giving administer group permissions. I have been reading all you posts about this issue https://drupal.org/node/1946518.
Any update?? My whole website is based on having subgroups and user need to create subgroup otherwise it defeats the purpose of having subgroup if user with administer group permissions can only create and that will give him right to create in any group rather than just one.

@Roysegall - Group manager full permissions is checked, I don't think that its issue with group manager. Anybody who has rights to create a group should be able to create a group which is also a group content.

What about the OG access fields permissions:

I don't need support i'm just asking if they checked the og vield access permission.

@ RoySegall - yes I have checked all the permissions you mentioned above and still its not working.

@Patribu- Good to hear that you will be working on this issue..
Right now I have asked user to first create the node and then edit it and check that its a group and then save it again but that's not how its should work. Appreciate your input.

I can confirm the exact same behavior on a fresh install of 7.26

In addition I get the following message after I add an entity reference field with widget 'OG Reference' to my 'node' content type.

Notice: Undefined index: entity keys in entity_extract_ids() (line 7716 of /var/www/smartertravel.piquant.ie/includes/common.inc).

The message only appears after saving the field (not at clear cache or cron)

Thanks for the thread above - saved my sanity!

Hi - I am just logging my experience with this here - hopefully useful to somebody.

It would appear to me that OG field permissions has a problem with the order in which it evaluates permissions when creating new content. Here is a snap of my OG settings:

Continuing on a new comment because I can't figure out a good way to upload images here :)

A content creator is assigned 'Manager'. I have purpose turned off permissions to the 'Body' field to illustrate. Here are the permissions on the node:

I have removed all 'audience' entity link fields on the content type for now, so my manager is able to create a new content instance in one step, but the field permissions are NOT respected in the initial creation:

As soon as the new node has been created, OG field permissions kicks in correctly and behaves correctly:

And when they edit the node, the behaviour is also as expected:

Pretty much a functionality killer for a large chunk of workflow scenarios? I would like to help resolve this, but my expertise is not in coding and module development.

So I've been digging into this issue on behalf of a client, and the problem is the way that og_field_access_field_access() behaves for new groups.

When a new group is being created, og_field_access_field_access() will iterate through groups the logged in user is members of and determine if the user has the correct field permissions on any of those groups, and if so it will be granted said permissions on the new group they are creating, which of course means that if the user has no groups, or no groups with the correct permissions, they won't have the correct permissions when creating the new group.

This does seem like a bug to me.

Patch changes things to instead of looking through groups the creator is a member of it uses the permissions of the roles that the user will be promoted to upon the creation of the group, which to me makes perfect sense.

The patch itself seems wrong -- you should always use the API provided by og to check access, which is og_user_access(), rather than checking roles.

I must admit I don't fully understand the problem. Maybe attach a simpleTest would help me understand :)

@Amitaibu,

The problem is that og_user_access() requires a group to exist, yet this is during the creation of a group, so how could you possibly use that function at this point?

This was done on behalf of a client, so I can't really spend any more time on the issue myself, but I don't want it to be lost due to misunderstandings as it seems like a fairly major issue. Hopefully someone else affected by the issue can have their say.

Thanks for your work in the patch Deciphered. It's works. All field data is saved like it should.
BUT, i have tested a little more and now all group content fields are gone, i can only add a title.

I'll change this to Critical since its very important.

I came across the same issue. I am trying to create a group that is group content and only admin can do that. Someone in a forum said we should use Rules and subscribe user to the brand new group upon creation. But I cannot make it happen. Please help!

@Nikrene,

Apply the patch from #24, problem solved.

@FAAREIA

Same behavior for me!

@Deciphered

After applying your patch from #24 creating nodes which is a group and group content works.

BUT: creating content which is only group content ended in the behavior FAAREIA describes in #27

Hello
I have been reading this issue since I was hoping to solve another one that I have, but having read it, I must admit I am completely confused why you guys think this is a problem, isn't this what og_subgroups does, if it is set up correctly?? I am not an expert like most of you but I have used this set up without an issue and I hope it can help and please correct me if I am wrong on this.
Essentially you want your content type to be a group, but have a parent group; meaning to be a content of that group as well as having group characteristic like members etc. That's what og_subgroups does, right (provided, you set it up correctly)?
The only thing you must pay attention, if you do use og_subgroups is when adding the access field for the group content, you must also add the access field for group (one without the other in this kind of content type will cause error) it is essential, and I think that's what's happening here. If you really think about it, this does make sense, group -> group access group content -> group content access and when one content type is both, then needs both since each of these access fields target a specific area if you will.
The reason for not getting error on your set up when og_access is not enabled because then organic group is most likely on auto pilot on every thing and follows a very set scenario and doesn't need validation anymore from what I understand in a non-technical term that makes sense to me (Although I have not tried what you suggest, since I always had og_access enabled).

This is the set up. Create a content type and call it team for example. Make this content type group but also group content. Under organic group field setting admin/config/group/fields add both group visibility (group access field) AND also group content visibility (group content access field) to this content type. Then go back to manage fields of your team content type and edit this two and set it the way that meets your need. You can also give permission to a specific group role to edit these fields and change it. To put it another way, consider organic group permissions your best friend, if you enable og_field_access, but keep in mind you are doubling your work for setting up permissions but it truly does a wonderful job if you need specific control over things.

This set up works, I am using it right now with no error and i checked the database (I also tested it through paths and views) and the fields are there, my own issue is caused by use of field-permissions and I am trying to find a way to set it up differently so i have a wider net but still some control, but that's neither here nor there in regard to this issue.

I've had the same problems as described above after migrating an existing site from OG1 to OG2. We need the og_field_access module active for the permissions we have setup already, and not currently prepared to install the og_subgroups module.

We have a mix of content types most are group content, one is group only and one is both group content and group. The patch in #24 works for the content type that is both a group and group content but it doesn't fully solve the issue for us as this then hides the fields on a group content only content type.

So I have adapted the patch in #24 so that it is only used when it's the specific content type that is both a group and group content and this now works on initial tests.

Here's the code I've used where the content type is called 'my_group_type' - if you use this code then replace this with your own content type name.

  /**
   * PATCH:
   * based on https://www.drupal.org/node/1950894#comment-8727889
   * Modified to only be used for adding new content type that is a group and group content
   */
  if ($entity->type == 'my_group_type') {

    if ((!$id || isset($entity->is_new)) && $op == 'edit' && (og_is_group($entity_type, $entity) || og_is_group_content_type($entity_type, $bundle))) {
      // This is create form of a non-saved entity, so we check permissions to
      // access the field, for all the roles the user  will be assigned.
      $name = 'og_group_manager_default_rids_' . $entity_type . '_' . $bundle;
      if ($rids = variable_get($name)) {
        $role_permissions = og_role_permissions($rids);
        foreach ($rids as $rid) {
          if ($role_permissions[$rid][$perm] == TRUE) {
            return TRUE;
          }
        }
      }
      return FALSE;
    }

  } else {

    if (!$id && $op == 'edit' && (og_is_group($entity_type, $entity) || og_is_group_content_type($entity_type, $bundle))) {
      // This is create form of a non-saved entity, so we check
      // permissions to access the field, for all the groups the user is a
      // member.
      foreach (og_get_entity_groups() as $group_type => $gids) {
        foreach ($gids as $gid) {
          if (og_user_access($group_type, $gid, $perm)) {
            return TRUE;
          }
        }
      }
      return FALSE;
    }

  }
  /* END OF PATCH */

Closed #1835740: Odd behaviour when creating a node that is BOTH a group and a group content as seems to be a duplicate of this issue.

The code that is returning access as FALSE is the following which is located at the bottom of the og_field_access_field_access function:

//....
  // Return result only if the entity is related to OG.
  $access = og_user_access_entity($perm, $entity_type, $entity, $account);
  if (!is_null($access)) {
    return $access;
  }

The patch from #24 is doing whatever it can to not get to the bottom of the function.

I moved og_user_access_entity call above the "if" statement, thus allowing for proper check to the field inside the "if" statement. Inside the og_user_access_entity function the following is happening and causing the issue.

    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;

Prior to the patch the $result was being returned as FALSE, after the patch the result is still FALSE but allowing an override to be done inside the loop of user group permissions.

small spacing adjustment to the proposed patch

Checking to see if this passes the failed test. It seems very odd to have to work around a unit test that permits itself to edit the field and says it shouldn't be able to. I assume it wants code to check and see if user can create or update the content.

    // Change permissions and assert user can view the field.
    $permissions['update body field'] = 1;
    og_role_change_permissions($anon_rid, $permissions);
    $this->drupalGet('node/' . $node->nid . '/edit');
    $langcode = LANGUAGE_NONE;
    $this->assertFieldByName("body[$langcode][0][value]", $node->body[LANGUAGE_NONE][0]['value'], t('Non group member can now edit field.'));

If this fails, then let's not give anon members access to edit any field?

the problem is that the group that is also a group content use the same field "og_group_ref" and when you change it in some group its changing also in the other group.
what work for me was easy:

go to "admin/config/group/fields"
add new field such ass"og_group_ref2" and choose the specific node in the Bundles selection
now go to "admin/structure/types/manage/specific_node/fields" after you see the new "og_group_ref2" that you create earlier you need to delete the old "og_group_ref" field.
that is all.

We found the same issue while creating a new node for a content type which was as a group and group content both.
We have fixed this issue using attached patch.

We found the same issue while creating a new node for a content type which was as a group and group content both.
We have fixed this issue using attached patch.

The patch in #50 worked for me.

Using the patch in #50, here is the patch against the latest dev version (7.x-2.1+0-dev).

I have encountered this bug as well. I'm running 7.x-2.9.

I confirmed that it isn't just my instance by testing on simplytest.me.

Here's how:

• Set up simplytest.me og-7.x-2.9 sandbox.
• Enable organic groups field access
• Enable organic groups UI
• Create Group content type, check the "Group" checkbox under the Organic groups tab.
• Create Subgroup content type, check the "Group" and "Group content" checkboxes under the Organic groups tab. Select "Group" as the target bundle.
• Edit the Group group permissions and give Members the "View Groups audience field" and "Edit Groups audience field" permissions.
• Edit global permissions and give Authenticated users permission to create and edit Group and Subgroup content types.
• Add "Tester" user.
• Use Tester to create a Group "A".
• Use Tester to create a Subgroup "B" while selecting Group "A" as it's parent.
• Edit "B", Group A is no longer selected in the og_group_ref field. (See EditSubgroupRightAfterCreate.png)
• Select Group A, and save.
• Edit B again, Group A is now selected in the og_group_ref field. (See EditSubgroupAfterEditAndSaveSelectingGroupAgain.png)

I see the same behavior when I select the 7.x-2.x Branch on simplytest.me.

I tried to use drush make to patch with #54, but it failed.

og-7.x-2.x-dev downloaded.   [ok]
Unable to patch og with og_field_access-1950894-54.patch.

@durgeshs, can you explain the logic behind your patch? I manually modified og.module, line 2247, in the 7.x-2.9 version of OG to match your patch, and that fixed the issue.

From what I can tell, that change is meant to tell og_user_access_entity() to return TRUE when og_user_access() returns NULL.

Is the entity being checked the new subgroup node, or the parent node?

Here is my attempt at a patch. Apologies if I screw something up. I haven't submitted many patches before. Based on #50.

Let the testbot run the patch with 'Needs review' status. Thanks for the patch @jerrac

Have a similar installation of OG (not using using Organic groups field access, however) with a setup where users can select a group to join upon user registration. Once the selection at registration was configured, this issue popped up. Administration users could create groups prior to this.

Applied patch from #57 and the problem is fixed. The logic appears sound as pre-patch, it assumes that every situation will have the permissions in play. I haven't looked at everything, of course, so, I could be incorrect.

In either case, this patch allows group nodes to be created by administration level roles without insisting there is a field permission out of whack somewhere.

Spoke too soon. The issue doesn't appear to be repaired. Digging into this further...