I have:

- Closed group
-- Closed sub-group

Users are registered manually, so memberships are selected at this point. Currently, it's not possible to propagate membership if I select the sub-group only, as the code doesn't allow it.

I wish to have this overridden somehow, could be a setting or just a variable. Or maybe, let it propagate if the sub-group is also a Closed Membership (or Invite-only)

CommentFileSizeAuthor
#11 membershipPropagation.patch1.33 KBAnonymous (not verified)
#10 membershipPropagation.patch1.24 KBAnonymous (not verified)
#8 1190488_2.patch2.71 KBrobcarr
#4 1190488.patch2.26 KBrobcarr
#6 1190488_1.patch2.46 KBrobcarr
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

MauPalantir’s picture

I have exactly the same problem... I need user propagation when the group admin adds a member to a subgroup

mindaugasd’s picture

subscribing

robcarr’s picture

Title: User propagation on "Closed Membership" groups » User propagation toggle on "Closed Membership" groups
Version: 6.x-1.0-beta2 » 6.x-1.0-beta3

It seems there are 2 schools of thought on this: propagation should happen regardless vs group joining criteria should be adhered to (the inverse request of this issue is #1080298: User propagation adds users to non open groups ... ). As there seems to be a lot of of issues raised around this issue, it seems that there are 2 distinct use case for this module, and it would be nice to cater for both.

So, I agree with @franz, there should be some sort of override toggle for overriding the group membership requests available.

robcarr’s picture

Status: Needs work » Needs review
FileSize
2.26 KB

A bit of hacking this morning and and I've added a 'Override Group Joining Criteria' option on the propagation page. Seems to work fine for the og_subgroups_prop module, although only tried the parent direction so far.

Rolled against 6.x-1.0-beta3... not tried against DEV, but probably worth a shot. Very tempted to correct typos in the $form['propagte_content'] but life's too short. Please review and change to RTBC if it seems fine (although may need to be re-rolled against DEV)

robcarr’s picture

Status: Active » Needs review

Actually a bit more testing... If the override is used, and users are subscribed by propagation to a 'Closed' parent group, that parent group still requires final admin approval. Not quite sure that's what's exactly needed for this generic use case but it works well for my current project.

Any thoughts?

robcarr’s picture

FileSize
2.46 KB

And another patch which is a full override so that no final approval is needed.

Any thoughts?

franz’s picture

Status: Needs review » Needs work
+++ b/og_subgroups_prop.install
@@ -8,6 +8,7 @@ function og_subgroups_prop_uninstall() {
+		'og_subgroup_propagate_join_override',

this needs soft-tabbing

+++ b/og_subgroups_prop.module
@@ -122,10 +122,11 @@ function og_subgroups_prop_propagate_user($op, $gid, $uid, $args = array()) {
+		$override_selective = variable_get('og_subgroups_propagate_join_override', 0);

again

Apart from coding standards, seems a nice solution.

robcarr’s picture

Status: Needs review » Needs work
FileSize
2.71 KB

Had another rethink and now changed the logic so that you can select either:

  • no group joining override (default - and current og_subgroups_prop behaviour)
  • a partial override (that still needs parent/child group admin approval)
  • a full override

This should meet most use cases.

So re-roll of the day #3. Hopefully no tabs.

robcarr’s picture

Status: Needs work » Needs review
Anonymous’s picture

FileSize
1.24 KB

If I have a closed group, only administrator can subscribe a user.
So, I made a patch to propagate the membership to the soubgroups only if an admin made the subscription.
In this way, we follow the standard behavior, without the need to force it.

Anonymous’s picture

FileSize
1.33 KB

This is the new patch that makes subscribed members approved

cspiker’s picture

The patch in #8 works well. Seems like a good solution.

Sutharsan’s picture

  • #8 only has settings to "override" when adding membership. In my use case it should have the same behaviour when removing membership too.
  • I have difficulty with the wording of "override". It propagates membership to open groups or to all groups.
  • I prefer sensible defaults, and therefore add my + 1 to the #11 patch.
  • Instead of adding zillions of options, I'd suggest to add a hook to change the behaviour on a per group basis.