variable membership type for group type

Is #1872016: Widget does not filter by configure membership type a duplicate of this issue?

Ah yes I see the difference now.

I'd like to be able to use different membership types for a single group type...

Call me crazy, but didn't this functionality exist in 1.x? I've been trying to set this up in 2.x, myself, and getting nowhere. I need to have three membership types that are distinct by the length of time they are permitted to access a single group.

That can be done without coding:
First group-audience field attached to the node referencing the group will have default membership
A second group-audience field (i.e. field with another name) will reference group with another membership-type.

Who adds that to the docs? :)

> It feels really unintuitive to have a field called 'group **audience**' on users, when they are members.

You can create a field in any name you want, via the regular field UI. MAke sure to set the selection handler to "OG" and the widget to be "OG widget", and from that point it's a "regular" group-audience field.

@joachim Are you not seeing a dropdown for "OG membership types" below "Entity selection"? "Mode" should be set to "Organic Groups".

I would be happy to write up some documentation once I get it sorted out myself. :)

After reading through this and this and this, I did attempt to add multiple Group audience fields, but through OG field settings (admin/config/group/fields), which of course won't permit more than one.

So now I've got three Group audience fields added to User via Account settings (admin/config/people/accounts/fields). Now the form at Group > Add members (group/node/%/admin/people/add-user) displays each of the membership types in the dropdown select. Selecting one loads the fields that were attached to each type via OG membership types (admin/config/group/group-membership).

Yay! Almost there!

Questions:

1) Is there some way to edit the values of the fields attached to a membership type after a member has been added? If not, it's a dealbreaker and back to square one for me. :(

2) Adding multiple Group audience fields to User adds superfluous stuff to the user edit form (user/%/edit). Now I've got three fieldsets, each containing the "Your groups" dropdown and "Other groups" autocomplete. First, is this expected? Second, is my only option here to sneakily hide these fields via hook_form_alter() or some such?

I appreciate your patience, @Amitaibu. Believe me, I spent a huge chunk of time on this before I dared bother anyone. Thanks!

Referenced:

#1168428 Work out membership types
#1263588 Allow having multiple group-audience type fields
#1342632 Deprecate OG group entity

I would be happy to write up some documentation once I get it sorted out myself. :)

Deal :)

1) Is there some way to edit the values of the fields attached to a membership type after a member has been added?

Sorry, I don't understand what you mean, can you explain?

Now I've got three fieldsets, each containing the "Your groups" dropdown and "Other groups" autocomplete. First, is this expected? Second, is my only option here to sneakily hide these fields via hook_form_alter() or some such?

You are seeing this only because you are an admin. A "regular" user won't see it as OG is already hiding it for you.

@joachim, @othermachines

This specific issue is very important for me to make clear, and use your help to think of the best way to explain it to the community. The idea of having multiple group-audience fields is what makes 2.x much more customizable than 1.x
I know the UX also sucks, as there isn't a clear way currently of adding a second group-audience field, so ideas (or better patches) are welcome.

> A good use case (mine at least) is a date field that holds the date at which this membership expires. You would set the expiry date when you add the user to the group, but you might also want to change the date later on.

There isn't currently a UI to edit an OG-membership. (this is something I wish Entity API module would provide in a generic way, so also Message module can benefit from it).

> is a date field that holds the date at which this membership expires

Reminds me I've created an example module for this in my sandbox

(@joachim) I'm not managing to edit the values of fields when adding a user to a group with a fielded membership type at all! How do you do it?

Hmm. Are you still not seeing the type selections on the Add member form? Here's mine (see attachment). Each of the options under "Field name" is a membership type. "New AAA Member" is shown as selected, along with its custom date fields. If you're not seeing this, let's backtrack and figure out what step was missed.

(@joachim) I assume what is meant here is:

0. Create a custom membership type 'foo' and add some fields to it.
1. Add a user to a group using the 'foo' membership type. Set some field values on the membership (this is the bit I'd like to do and can't figure out how).
2. Later on, edit the user's membership, and change the values.

A good use case (mine at least) is a date field that holds the date at which this membership expires. You would set the expiry date when you add the user to the group, but you might also want to change the date later on.

Thanks, that is exactly what I meant! I'm pretty sure there's no UI for this, yet. Today I've been looking into how to go about building one.

(@Amitaibu) You are seeing this only because you are an admin. A "regular" user won't see it as OG is already hiding it for you.

Of course! Sometimes I forget I'm super. :) However, my worry is for my non-techy client, who will be administering the site (and its groups). I'll have a closer look at what I can do with permissions. Thanks!

(@Amitaibu) This specific issue is very important for me to make clear, and use your help to think of the best way to explain it to the community. The idea of having multiple group-audience fields is what makes 2.x much more customizable than 1.x
I know the UX also sucks, as there isn't a clear way currently of adding a second group-audience field, so ideas (or better patches) are welcome.

I am already thinking on this. Should be easier once I've fully wrapped my head around it. For me it was hardest to rationalize having to create a field to explicitly represent a membership type. Even though I know (now) it's what I'm supposed to do, throughout the process my brain is saying, no, no, that can't be right, can it? Anyhoo, will think on it.

(@Amitaibu) There isn't currently a UI to edit an OG-membership. (this is something I wish Entity API module would provide in a generic way, so also Message module can benefit from it).

Darn. Oh, well. I figured. Entity API - yes, makes sense.

(@Amitaibu) Reminds me I've created an example module for this in my sandbox

Yes, I have looked at this and was happy to find it. The code will help me along in handling membership expiration. Overall, how compatible is this with 2.x?

Thanks!

> Overall, how compatible is this with 2.x?

AFAIK 100% :)

@Amitaibu and @joachim -

Trying to work out how to limit specific membership type bundles to certain groups.

I have two node type bundles (groups): "Solar" and "Lunar". I have the default membership type, plus two custom membership types: "Human" and "Vampire". (Not really, but bear with me.)

To the user bundle I add a Group audience field, titled "I Am Human". Field settings are:

- Target bundles: Solar
- Membership type: Human

Likewise, to the user bundle I add another Group audience field, titled "I Am Vampire". Field settings are:

- Target bundles: Lunar
- Membership type: Vampire

Now, on the "Add people" page for my "Solar" group, I expect to see two selections under "Field names":

- Default
- I Am Human

Instead I see:

- Default
- I Am Human
- I Am Vampire

Settings aside the fact that vampires do tend to appear where they don't belong... Am I missing something crucial about how this is supposed to work?

As a follow-up to my last post: Should I be able to limit specific membership type bundles to certain groups? It appears that this is permitted, but it doesn't appear to be working for me.

Once I get this clarified I'll be able to document at least the basics (and point out the limitations). I've never contributed online documentation before (as opposed to READMEs). Can someone give me a nudge in the right direction? Do I start an issue (to be reviewed) or just have at it?

Without a UI to edit membership type fields, I've had to look at other options. I just don't have time to customize that right now, but will definitely be coming back to it as I think it's a pretty important feature.

Thanks -

@othermachines, Any chance you can attach a db-dump with the problem, and simple steps to reproduce.

@joachim, on a clean installation this work fine for me. Can you give steps to reproduce.

@Amitaibu If you could start by answering my question, that would be great: "Should I be able to limit specific membership type bundles to certain groups?" If the answer is no, there isn't a problem. (And if that wasn't simple, I guess I'm probably the wrong person to write documentation.)

Thx -

* Edit: "certain groups" = referring to different node types assigned as group, not different nodes of the same node type:

Node type "State" (Group)
- membership type "congressman"
- membership type "senator"

Node type "City" (Group)
- membership type "mayor"

> "Should I be able to limit specific membership type bundles to certain groups?"

No. This feature doesn't exist.

Then, if I understand this correctly, this is indeed a feature request...

@Taxoman

Good question. I would let @joachim answer to whether he was able to accomplish the task he originally set out to do.

Regarding the rest of the discussion, I think we have an existing feature that hasn't really been built out, yet, and it's creating quite a bit of confusion. These "feature requests" might already exist elsewhere in the queue:

1. Add UI for editing membership type field values

I am reminded that @joachim opened a separate issue here: fields on membership types - https://drupal.org/node/1871226

2. Allow users to assign membership types to particular groups

This may be part of what @joachim was trying to do, above. I'm not sure. The only way, as far as I can tell, to enable a custom membership type is to add a Group audience field to an entity type. In the field settings, you can set a group as a "Target bundle", and yet it doesn't actually do anything. So, I don't know - is this feature request, bug, or brain fart (my own)? If a feature request, I would say it's probably a pretty important one. If brain fart, well, I may need help of a different sort. :)

@joachim My scenario was the same, except I had flexibility in that the duration settings could be per-user, not per-group. Per-group was my original preference, but I gave up on OG membership types and used a Profile2 profile type instead (screenshot attached).

Your scenario might work with OG membership types IF:

1. you don't need to edit your users' expiry dates after they have been set (unless you build a UI for editing OG membership type fields);
2. you are using the same two membership types for all groups (since you can't assign a membership type to a particular group).

Expiring users: I have recently discovered the magic of using VBO with Rules. Works quite nicely for this purpose.

I think I'm trying to accomplish the same thing this issue is struggling with. I'm building a site where the questions you need to answer to apply to membership in various groups are different. I only have/need 1 group content type ("circle"). For each instance of a circle (e.g. for each separate node), I want to be able to select which og_membership bundle to use for users trying to subscribe to that specific group. Is this the right issue to discuss, or should I open a separate one?

I fear the "right" way to solve this is some magic custom field you can attach to group entities that records the og_membership bundle you want to use for memberships in that group. Then, inside og_membership_create(), if such a field exists on the group entity, use the value in there. Otherwise, use the value in the current audience field settings.

Does that sound about right? Should I attempt to proceed with a generic solution like this? Any objections to this approach?

Thanks!
-Derek

If someone is still interested, it seems further discussions have moved to Github.
I went ahead and created a followup issue on the queue loading custom membership type in group