How to make an existing private OG group and its nodes public?

Question

I use Drupal Commons 7.x-3.12 (uses OG 7.x-2.7). There, I have a private group with private posts. (Means, the group node uses privacy settings "Joining requires admin approval" and "Hide contributed content from non-members").

I want to make this private OG group public, and all content nodes in it.

So I tried and set "Privacy settings: Any site member can contribute" when editing the group node, and rebuilt the permissions. This made the group node publicly visible, but none of its content nodes – neither those created before nor after this change.

Answer 1

How to make your private OG group public, and existing posts in it:

1. Make the group node public. Edit the group node and set "Privacy settings: Any site member can contribute". You did that already. It should be all there is to do, but due to bugs we have some more steps:

2. Make existing content nodes public. Set the group_content_access field of existing posts to "Public - accessible to all site users". For that, run the following command, replacing 3183 with the node ID(s) of your own affected group node(s). We use drush here, but you could also run it in the database directly.

   drush sql-query "UPDATE field_data_group_content_access 
     SET group_content_access_value = 1 
     WHERE entity_type = 'node' AND entity_id IN (
       SELECT etid
       FROM og_membership
       WHERE entity_type = 'node' AND group_type = 'node' AND gid IN (3183)
     )"
   

   _{^{(Note to self: Don't copy&paste such commands to a Freemind rich text node for adapting before executing. Saving, re-editing and then copying the node content will convert spaces to non-breaking spaces, making the SQL commands fail with confusing error messages.)}}

3. Check results. Check that the group_content_access field is now 1 for all nodes in your group. To do that, execute this, again replacing 3183 with your group node ID(s):

   drush sql-query "SELECT entity_id, group_content_access_value 
     FROM field_data_group_content_access 
     WHERE entity_type = 'node' AND entity_id IN (
       SELECT etid
       FROM og_membership
       WHERE entity_type = 'node' AND group_type = 'node' AND gid IN (3183)
     )"
   

4. Make future content nodes public. Due to a bug, the Drupal Commons setting "Any site member can contribute" that we changed above does not properly change the relevant OG setting. This causes new posts to be still "Private - accessible only to group members" (value 1, in this case). So we have to change the OG setting ourselves. To do that, execute this, again replacing 3183 with your group node ID(s):

   drush sql-query "UPDATE field_data_field_og_access_default_value 
     SET field_og_access_default_value_value = 0 
     WHERE entity_type = 'node' AND entity_id IN (3183)"
   

5. Rebuild permissions. Either do click the button in admin/reports/status/rebuild, or run:

   drush php-eval "node_access_rebuild();"
   

Background knowledge and details

• Setting the group node to "Privacy settings: Any site member can contribute" as you did does not affect already existing group content nodes because they have a separate field group_content_access that has been set at node creation to value 2, according to the then-active group settings (2 means "Private - accessible only to group members", as can be seen when editing a content type's group_content_access field via the Drupal CCK interface). So you have to set this field somehow manually to 1, which means "Public - accessible to all site users".

• In order to change the group_content_access field, when using vanilla OG modules you can just change that in the node create / edit form as the field shows there. In your version of Drupal Commons however, it does not show there. This is a tweak via a hook, since Commons wants to simplify the group visibility logic by introducing the group-wide "Privacy setting" field. It means we had to resort to direct database manipulation above.

• The "Group content visibility" (group_content_access) field has a third value 0, meaning "Use group defaults". Using it leads to a fallback to the value of the "Group visibility" (group_access) field of the containing group, as confirmed here. It does not mean a fallback to group_content_access field of the containing group, as confirmed here (that field only exists if the group is simultaneously group content). Anyway, this fallback behavior is confusing and inflexible, as the fallback value does not allow to have a publicly visible group node with private content nodes. A rework is under discussion.

• Drupal Commons 3.x-3.12 and newer has a workaround for this that enables having a publicly visible group node with private group content nodes. It's done with the combination of the group's privacy settings you used ("Joining requires admin approval" plus "Hide contributed content from non-members"). This is only a workaround however, since it means that all group content nodes have to set their "Group content visibility" field to an explicit value (1 or 2) rather than the fallback (0). It leads to the manual effort when wanting to change a group from private to public later, as you tried. This should be considered a bug that is still awaiting its real fix. I want to report this to Drupal Commons, but have to re-test with the newest release 7.x-3.19 first.