Refactor og_group_ref field per OG API improvements

This should be done after #1961302: Streamline group privacy settings fieldset

Work in progress

Patch includes the WIP from #1964282: Streamline group privacy settings fieldset

The selection handler is working :)

Patching commons to enable og_access and the OG access fields.

Patching commons_groups:

• Adding privacy fields to groups and customizing their display.
• Forcing content of private groups to be private.
• Adding a selection handler for handling the privacy fields.

Ready for review.

+++ b/commons_groups.features.field_base.incundefined
@@ -10,6 +10,59 @@
+  $field_bases['field_privacy_settings'] = array(

• Lets change this name to be field_og_subscribe_settings().
• This should be moved into commons_groups_field_definition(), so it can be added dynamically to all group-content, as they are enabled.
• When a user changes the permissions on the permissions page, this field should be synced, accordingly

+++ b/commons_groups.features.field_base.incundefined
@@ -10,6 +10,59 @@
+  $field_bases['field_private_content'] = array(

This field should be moved to commons_groups_privacy() (and all the logic related to it).

This means that we can indeed decouple #5 and move it to it's own issue. for real :)

@amitaibu The commons_groups_privacy module is not currently enabled by default. Should we enable it?

> Should we enable it?

No. They want to avoid having node-access if not needed.

@amitaibu There's a slight problem moving the selection handler to commons_group_privacy; The og_group_ref field defined in commons_group is supposed to use that handler.
Perhaps it should use the default OG selection handler and be switched to the group_privacy handler when group_privacy is enabled?

No the selection handler stays in commons-groups.
Just the private field moves to the privacy module

When a user changes the permissions on the permissions page, this field should be synced, accordingly

og_group_permissions field should be added on every group, and it's default to be "Override global roles and permissions", and hook_field_access() it, so it's always overridden.
When the field field_og_subscribe_settings value changes, we need to setup the permissions.

Something along the lines:

/**
 * Implements hook_node_insert().
 */
function commons_groups_node_insert($node) {
  $permission = $wrapper->field_og_subscribe_settings->value();
  $og_roles = og_roles('node', $node);

  $anon_rid = array_search(OG_ANONYMOUS_ROLE, $og_roles);

  $permissions = array(
    'subscribe' => $permission == 'join',
    'subscribe without approval' => $permission == 'approval',
  );

  og_role_change_permissions($anon_rid, $permissions);
}

Since we don't have a hook for permissions change, lets form_alter() and remove those option from the UI.

Patch for commons_groups containing all of the above.

Minor nitpicks:

+++ b/commons_groups.moduleundefined
@@ -24,6 +32,58 @@ function commons_groups_entity_view($entity, $type, $view_mode, $langcode) {
+  // Wrap the privacy fields with a fieldset.

Return early, and hide field if og_access is disabled.

+++ b/commons_groups.moduleundefined
@@ -456,19 +516,88 @@ function commons_groups_default_rules_configuration_alter(&$configs) {
+ * When the node's group is private, force the node to be private.

node => node's group-content

Including fixes from #15.

+++ b/commons_groups.module
@@ -24,6 +32,64 @@ function commons_groups_entity_view($entity, $type, $view_mode, $langcode) {
+  // Block the subscription field when editing an existing group since there's
+  // currently no hook for changing the actual permissions.
+  if ($form['nid']['#value']) {
+    $form['privacy_settings']['field_og_subscribe_settings']['#disabled'] = TRUE;

I actually thought doing it the other way -- hiding those permissions from the OG-permissions page.

+++ b/commons_groups.module
@@ -217,6 +283,11 @@ function commons_groups_system_info_alter(&$info, $file, $type) {
+            $info['features']['field_instance'][] = "$entity_type-$bundle-field_og_subscribe_settings";

That field should be out-side of Og-access. It's not about access, it's about the subscribe settings (e.g. subscribe with or without approval)

Also need to send an email when a message is sent.

Re-rolling #17 - See separate diff file.

Patch removes commons_group_privacy and fixes synchronization between the subscription settings field and the relevant permissions.
Not tested at all yet.

Currently the privacy field is not created when the module is installed without og_access. I assume we'll need to add the field manually in case og_access is enabled later, right?

> Comments #19 and 21 were meant to be on #1975198: [Meta] Trusted Contacts & Private messaging.

I was just about to write scope creep ;) @ezra can you please open a separate issue for notifications (+ explain there what "accept invitation" means)

> If we can detect when og_access is enabled and do a features_revert on the field base and instance components for Commons_groups,

@itamar, we can hook_modules_enabled() and do the features revert. We need to see the features revert is only on our module, so we don't time out.

Re-rolling #20:

- Fixing problems in the subscription field synchronization.
- Creating the privacy field anyway and hiding it when og_access is disabled. (To avoid the need in feature revert when enabling og_access).

Notice that the patch depends on #1975844: Create hooks for notifying when OG role permissions are changed, which is already in OG's dev.

Fixing status.

Re-rolling #27:

Removing field instances declaration per #27 + Cleanup.

- With a second, non-admin user account, I went to the newly created private group, and saw that I was presented with a "create post" link.

This setting is currently synced with the subscriptions permissions and does not determine the ability to post content to the group.

This setting is currently synced with the subscriptions permissions and does not determine the ability to post content to the group.

That's wrong, the selection handler does check for this field, so settings back to needs review.

Also, note that instead of features_revert if og_access() exists, we simply hide the field if it's not in use -- IMO it's a more sane workflow.

However, my expectation is that as a non-member of the private group, I should *not* see the create post link when viewing a private group where I am not a member.

Overhauled commons_groups_og_user_access_alter() to look for the new changes. btw, we need to find a better term for "private" group. It's not really "Private" (i.e. node-access), it just doesn't allow users to join without approval. Maybe "Moderated groups"?

Patch makes sure to hide the field when not needed.

@itamar
We actually need to act on Og-access being enabled, and add the relevant fields using og_create_field()
This should be done in 2 places:

• hook modules enabled() -- When OG-access is enabled
• hook_field_attach_create_bundle() -- When a new group-content is added, after OG-access is already enabled

@ezra-g, I believe those fields should not be in features, as they have specific settings for OG + we solve the problem of adding a new bundle after OG-access is enabled.

Re-rolling 34; Creating the access fields when og_access is enabled and when a new group content type is created.

Fix access contorl, @itamar please check.

+++ b/commons_groups.moduleundefined
@@ -415,26 +415,22 @@ function commons_groups_og_user_access_alter(&$perm, $context) {
+    // Group is public.
+    $access_create = FALSE;

I believe it should be $access_create = TRUE;

Re-rolling #37.

I made the following tests (On the patch attached here) and all worked as I expected.

With OG Access off:

Group subscription is not public - "Joining requires approval":
- Group member is able to post content and sees the post button.
- Pending / Blocked group member and non-member are unable to post nor see the post button.

Group subscription is public:
- Group member / Non-member are able to post.

OG Access is on:

Group subscription is public:
- Group member / pending member / non-member is able to post.

Group subscription is "Joining requires approval":
- Non-member is unable to post.

Re-rolling; Hiding the content access field.
I verified that the "Hide contributed content from non-members" setting changes the access setting on new group nodes.

Great!

@ezra-g, when testing make sure you have OG 2.x --dev

Re-rolling;
- Creating the access fields with features.
- Hiding the group access field and setting its value according to subscription settings.

Sorry about #43.
#44 doesn't install properly, we are working on fixing the issue and submit a patch later on. Stay tuned.

Fixing points A and B from #43.
Notice that when enabling OG access from the UI, the fields do not revert properly, but that was also the case for me with patch #43. When enabling OG access from drush, the fields revert but the instances are shown as overridden in the features overview even though they aren't.

@ezra-g I couldn't reproduce the privacy settings being overridden (A);
I'm able to create groups with "privacy settings" set to " Anyone can join" and it doesn't get overridden to "Joining requires admin approval". And so is the case when editing existing groups.
I tried both possibilities with and without og_access. Can you give me an advice on how to reproduce it?

B) When a non-member attempts to post into a public group, the node title isn't present in the autocompelte widget and there is no form validation error, but the resulting node isn't posted into any group.

I verified that this problem disappears when OG and Entityreference-prepopulate are updated to their latest releases. The attached patch updates them.

I'm leaving status as needs work because of #48.

@ezra-g I created a fresh installation from 7.x-3.x (But with OG and entityreference-prepopulate updated to their latest releases), and then performed exactly what you described on #51, and the group stayed as "Anyone can join".
So I'm assuming also this problem disappears with the latest OG and entityreference-prepopulate.