I'm somewhat new to drupal development, but could someone help me resolve this new issue we've discovered since upgrading the OG module I'd be very grateful. We've got a number of groups on our site that are public, but have the group content visibility left at default. Now whenever these nodes are updated the user receives an error and the content appears unpublished to them. Selecting either private or public group content visibility seems to prevent this from happening (admins access is needed to correct this), but I'm not sure this is intentional and I wonder if it may be a bug.

The error log reads:
"OgException: Cannot set visibility of node ID 525451 as the node group of type campus does not have the "Group visibility" field attached to it. in _og_access_verify_access_field_existence() (line 254 of /drupal/sites/all/modules/contrib/og/og_access/og_access.module)."

For that particular node, the actual node content type is "department", not "campus" as the exception error message reads. Group visibility (OG_ACCESS_FIELD) without a doubt is indeed set as the group node is public (with content visibility set to default), but for some reason the new "_og_access_verify_access_field_existence" function disagrees, and it grabs the wrong node bundle type.

I suspect new code in og_access.module might be the cause (lines 233-260):

function _og_access_verify_access_field_existence($node) {
  // Verify that the OG access field is attached to the group(s) content.
  $fields_names = og_get_group_audience_fields('node', $node->type);

  $groups_bundles = og_get_all_group_bundle();

  // Check each group audience field on this node type.
  foreach (array_keys($fields_names) as $field_name) {
    // Get the group entity type that this field points to.
    $field_info = field_info_field($field_name);
    $target_type = $field_info['settings']['target_type'];
// $target_type = 'department';
    foreach (array_keys($groups_bundles[$target_type]) as $bundle) {
      $instances = field_info_instances($target_type, $bundle);
      // Verify that the OG access field is attached to the group bundles.
      if (empty($instances[OG_ACCESS_FIELD])) {
        $params = array(
          '!nid' => $node->nid,
          '%entity_type' => $target_type,
          '%bundle' => $bundle,
          '%array' => implode(' .... ', $field_info['settings']),
          // implode(' ', $someArray);
        );
        throw new OgException(format_string('Cannot set visibility of node ID !nid as the %entity_type group of type %bundle does not have the "Group visibility" field attached to it. array == %array|| end', $params));

      }
    }
  }
}

If this function is pulling the wrong node bundle type for groups (where the group content visibility is set to default), it would also be grabbing the wrong content fields as the "campus" content type and "department" fields are completely different. If it's checking for campus fields on a department content type, I'm wondering if this may be why the og_access_field is returning as empty. $field_info['settings']['target_type'] for this node also appears empty, and I'm wondering if it's defaulting to the first group type in "$groups_bundles =og_get_all_group_bundle();" which would be "campus".

This is about as far as I've gotten tonight, but I hope I've included enough info where others may be able to help.

Thank you very much in advance.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jastraat’s picture

Just to clarify, what is the group type and what is the group content type that are involved in this error? Have you confirmed that the node with the error is still associated with the group you expect?

Forgive me if you already know this, but there needs to be a 'group visibility' field on your group type and a 'group content visibility' field on the group content type. Both those exist?

Poindexterous’s picture

Hi Jastraat,

Our group content types are:
Campus
Department

We don't use the Campus group type at the moment, the majority of our groups are Departments.
Both are node content types.

We have other node content types like articles, events, classes, etc. that we use exclusively for group content only. No other content types other than "Department" and "Campus" are being used to create OG groups.

Yes, both group visibility and group content visibility appear as they always have. The vast majority of our departments have group content visibility set to "public", and group content visibility set to "use group defaults". This problem had first arisen after the update, we have a user and OG role for "department managers". Whenever they tried to make a new revisions of their group node they were locked out of being able to access the node after they saved there changes.

A colleague of mine (with higher permissions than the department managers) noted that changing the group content visibility from "use group defaults" to one of the other options seemed to clear up the problem. That's when I dug into the logs and investigated the error messages. When the error messages seemed to be classifying the "department" group node as a "campus" node it seemed to offer a teeny clue.

If I were to try and replicate this on another site, I'd start out with the previous version of OG. Create two different group node types, making them public with the group content visibility set to "group default". Create a test role (drupal/og) that doesn't have "bypass all" but give an account with that role basic permissions to the group so they can edit it. Afterwards, update to the most recent OG module, log in with that test account and change some text in the group node body and see if the node will save without error, or allow access to the group node after that first save after upgrading.

Poindexterous’s picture

Just wanted to note that leaving the "group content visibility" at default also prevents a new group node from saving, same error with the wrong bundle type:

OgException: Cannot set visibility of node ID 555123 as the node group of type campus does not have the "Group visibility" field attached to it. in _og_access_verify_access_field_existence() (line 254 of /drupal/sites/all/modules/contrib/og/og_access/og_access.module).

So in our case this bug is preventing new groups from being saved unless we choose public or private for the "group content visibility".

jastraat’s picture

Could you export the configuration of one of your group content types to a feature so that it's possible to see if the node type configuration works correctly in a fresh install of OG versus one that was upgraded to 7.x-2.7?

cyborg_572’s picture

Status: Active » Needs review
FileSize
1.7 KB

I've just come across this issue as well. When attempting to save group content that uses the "Use group defaults" value for the group content visibility field, the _og_access_verify() function checks the entity type of the group reference field, and then makes sure all the group bundles of that entity type have the group visibility field.

The problem is, it might not make sense to enable group visibility on, for example, every group enabled node type if there's only one content type that actually requires the private/public setting.

I've attached a patch that checks the group reference field's target bundles as well, and only throws an error if one of the bundles that can be targeted doesn't support inheritance.

Status: Needs review » Needs work

The last submitted patch, 5: verify-access-field-existence-bundles-2496875-5.patch, failed testing.

cyborg_572’s picture

Status: Needs work » Needs review
FileSize
1.73 KB

Fixed the existing tests not pasting, although this probably could use some new tests

gauravjeet’s picture

Status: Needs review » Reviewed & tested by the community

have tested the patch in #7, it works fine for the versions >=7.x-2.7
can be merged into the module, no issues reported after applying the patch

brad.bulger’s picture

Version: 7.x-2.7 » 7.x-2.x-dev
Status: Reviewed & tested by the community » Needs review
FileSize
1.36 KB

I consolidated the code a bit and recreated the patch against 2.10.