I've enabled the OG Content Access module and my features are default. All the node types now have a group_content_access field. So far so good.
However, the field never shows up in the interface.

According to this page it should be fairly simple.

Can anyone shed a light on this? Am I missing something?
FWIW: I've tried it on a vanilla commons 3.2 too.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jpontani’s picture

Status: Active » Postponed (maintainer needs more info)
FileSize
56 KB

I just tried it on a clean 3.2 install, and can't reproduce. It shows up fine in the UI when I added the field to Posts.

jpontani’s picture

Version: 7.x-3.2 » 7.x-3.x-dev
Assigned: Unassigned » jpontani
Status: Postponed (maintainer needs more info) » Active

Works fine in 3.2, but in -dev, I am able to reproduce.

jpontani’s picture

So for some reason the group_content_access field has the '#access' attribute set to FALSE, hence why it's being hidden.

I tested this with a quick hook_form_alter with the following:

if (isset($form['group_content_access'])) {
  $form['group_content_access']['#access'] = TRUE;
}

The field now shows up properly. Still looking into the underlying cause as to the disallowed access to that field.

jpontani’s picture

So in commons_groups, we're apparently forcing FALSE on the group_content_access field, specifically:

function commons_groups_field_access($op, $field, $entity_type, $entity, $account) {
  // other code here
  if (module_exists('og_access') && in_array($field_name, array(OG_CONTENT_ACCESS_FIELD, OG_ACCESS_FIELD))) {
    return FALSE;
  }
}

Going to have a chat and will figure out why we're hardcoding this to hide this field and OG_ACCESS_FIELD.

ezra-g’s picture

Category: bug » support
Status: Active » Fixed

Commons provides an alternate UI for group privacy settings, as implemented in #1961302: Streamline group privacy settings fieldset and show in the screenshots there.

As a result, the default OG documentation doesn't apply to group privacy settings.

Let's add this to the Commons documentation.

ezra-g’s picture

Also, see commons_groups_node_presave() for where we set some of these values behind the scenes based on the simplified UI.

BarisW’s picture

Whoa.. So does that mean that is not possible anymore to create private nodes in public groups and vice-versa?
That would mean I have to form_alter everything back in, as the current site (I'm migrating into commons 3) uses that a lot...

RobKoberg’s picture

I did a search for field_og_access_default_value before posting https://drupal.org/node/2019057 but did not find this thread (so I am putting it on the page now :) ).

OK, so the answer on how to get a node to have private content can be done in one three ways:

a) set the group to "Joining requires an invitation. The group and content is hidden from non-members. " (edited)

b) set the field_og_access_default_value to TRUE for the group content type

c) edit the group content type instance as an administrator or someone with permissions that are similar to admin's with regard to content editing.
I don't think this last one will work unless "Joining requires admin approval" is checked which means the checkbox on the page will be ignored regardless, so I guess this is not really a way to do. Perhaps there should be an initial check at the top of commons_groups_node_presave() to see if $wrapper->{OG_CONTENT_ACCESS_FIELD} is already set to TRUE (i.e. by an admin or similarly permissioned user)

RobKoberg’s picture

Sorry, item C is totally incorrect. disregard it.

RobKoberg’s picture

Status: Fixed » Active

I have just talked to project managers about this content privacy change to the way groups works and was asked to ask if we can get the ability to set content visibility back. This is for a large educational app from Pearson that will most likely be hosted on Acquia Enterprise.

Our use case is for Teacher > Student groups where the content is private. Some of those students will be under 13 and we won't be storing emails for them (COPPA), so they won't get emailed updates (I know, don't get me started). We have a group unique identifier set at the group level. Students use that at registration time or later in a group finder to find the group and ask to be members. We don't want the teacher to have to invite students to each group they create.

Is there any chance of not hiding field_og_access_default_value and allowing any type of group to have private content? I understand what you are trying to do, but it won't work for us. I will either need to drop commons or try to maintain my own version of commons_groups (don't know if that will even work). I have reset to active in the hopes that it will be revisited soon.

BarisW’s picture

Just to share how I 'fixed' it:

<?php
/**
 * Implements hook_form_alter().
 */
function MYMODULE_form_alter(&$form, &$form_state, $form_id) {
  // Temporary fix to show the group content access form element.
  if (isset($form[OG_CONTENT_ACCESS_FIELD])) {
    $form[OG_CONTENT_ACCESS_FIELD]['#access'] = TRUE;
    $form[OG_CONTENT_ACCESS_FIELD]['#weight'] = 150;
    $form[OG_CONTENT_ACCESS_FIELD]['#attributes']['class'][] = 'hideable-field';
    $form[OG_CONTENT_ACCESS_FIELD][LANGUAGE_NONE]['#type'] = 'radios';
    $form[OG_CONTENT_ACCESS_FIELD][LANGUAGE_NONE]['#default_value'] = OG_CONTENT_ACCESS_DEFAULT;
    $form[OG_CONTENT_ACCESS_FIELD][LANGUAGE_NONE]['#description'] = t('Note; posts in private groups are always private.');
    $form[OG_CONTENT_ACCESS_FIELD][LANGUAGE_NONE]['#title'] = t('Privacy settings');
  }
}
?>

Plus the code below to add the privacy field to the BW Quick Post form:

<?php
/**
 * Implements hook_field_default_field_instances_alter().
 */
function MYMODULE_field_default_field_instances_alter(&$instances) {
  foreach ($instances as &$field) {
    switch ($field['field_name']) {
      case OG_CONTENT_ACCESS_FIELD:
        $field['display_in_partial_form'] = 1;
        break;
  }
}
?>
ezra-g’s picture

Status: Active » Postponed (maintainer needs more info)

We have a group unique identifier set at the group level. Students use that at registration time or later in a group finder to find the group and ask to be members. We don't want the teacher to have to invite students to each group they create.

I don't follow how that's related to group privacy settings. Commons Groups in Dev also allows people to request membership to private groups which prevents admins from having to invite people to join private groups.

We definitely want to keep Commons flexible and able to meet a variety of use cases so I'd like to better understand your needs here.

Whoa.. So does that mean that is not possible anymore to create private nodes in public groups and vice-versa?
That would mean I have to form_alter everything back in, as the current site (I'm migrating into commons 3) uses that a lot...

If that's an important feature, we could certainly consider supporting that as an option or addition to the current UI - I encourage you to submit a feature request for it.

ezra-g’s picture

Assigned: jpontani » Unassigned
RobKoberg’s picture

Assigned: Unassigned » jpontani
Status: Postponed (maintainer needs more info) » Active

But that is not the commons access field. I fear there will be problems if commons uses one way and we use another.

Btw, doing the form alter for the commons access field has no affect because it is handled completely different than regular form submission.

ezra-g’s picture

Assigned: jpontani » Unassigned
Status: Active » Postponed (maintainer needs more info)

Looks like 12-14 were cross-posts. Setting back to "needs more info."

RobKoberg’s picture

#15 ezra-g yes, my #14 was for BarisW #11.

Regarding #12, I don't see an example of a group with private content in the commons clean install (and choosing to populate with content).

Is it not correct that you have to set the Privacy settings to "Joining requires an invitation" which I assume means what it says. When I create a a group with that selection, as a different user, I can't even access the group page.

Or if that is all wrong, how do you setup a group with private content, but users can still see the group page and request membership?

ezra-g’s picture

how do you setup a group with private content, but users can still see the group page and request membership?

1) Make sure OG Access module is enabled.
2) When submitting a new group (with the latest Commons_Groups dev version), make sure the Privacy settings fieldset matches this screenshot:

Screenshot_6_13_13_4_40_PM.png

Does that resolve the issue for you?

RobKoberg’s picture

Will give it a try. Since I am using a different theme, that toggle is not happening for me.

Ideally that check box is not related to the one radio button or at least it relates to both anyone can join as well as administrator must approve.

I can see the argument for it not applying for private groups and it makes the UI better not to have that as an option globally available on the form. But the other two could use content privacy. We are trying to have the teachers do as little group admin work as possible, and thought it would be easier for them to remove people they don't want rather than have to approve people. A teacher may have thousands of students.

ceepeebee’s picture

Returning to the original issue:
"Group Content Access field is not displayed and thus cannot be used"

As stated above (see this page), the group content access field could be used to make specific content public even if the group is set to private (and vice versa)

Use case:
Most of a group's activity should be private, e.g. private posts, private wiki, private events etc.
But there are, for exapmle, some events non-group-members should be informed about, as well.

You need a private group (e.g. "Joining requires an invitation.") so that the group and its content is hidden from non-group members in general.
If you want to be able to set the group content visibility to public for specific content, e.g. one special event, you need to be able to access OG_CONTENT_ACCESS_FIELD, don't you?

@#14:I don't see that. Could you please explain your concerns?

As I understand #4 and #5 #1964282: Streamline group privacy settings fieldset had this option removed.
Here is the corresponding Feature Request to have it back again.

TuWebO’s picture

Issue summary: View changes

@jpontani from #4, did you figure out why it is hardcoded that way?
That leads to another problem if we want to show that field on node views. I've open a feature request #2207597: PATCH - Allow Group Visibility field to be visible on node view when og_access is activated for that. Maybe it is useful for someone.

isellakuria’s picture

Is there a way to have the Group Content Access field displayed?

The provided patch does not work for me.