I am wondering if the following use case is apropriate, feasible off label, or should not be done with OG7.
Use Case Example
A national club runs a web site and uses OG groups to manage membership in local, affiliated clubs. National members may (or may not) be members of a local club by joining their group. Via Rules, this changes where they pay dues, etc. So far so go.
The issue is that users may be members of more than one local club but only the first one they joined is where we send their membership packet, collects dues, etc.
To summarize, is there a way to identify (and integrate with Rules and Views) a "primary group" for the user?
Options
1) Use only OG. First, we can e.g. use Views to get group membership, sort and limit results to 1. Then we can use that for Rules. Optionally, we could use Entity Field Query to access the og_membership table directly. Optionally, we could add a field to the group content type that identifies Primary membership but then we'd need to use rules to set that properly if their membership changed.
2) Use OG with custom content type or entity. We could use OG for group functions but also place data in a custom field with Rules when a user joins a group. The benefit is that this separates the "primary group" function from OG. The detriment is that it's more complex.
3) Use only custom content. If the first two options really do not make sense, then we can abandon the OG functionality and only record the primary group in a custom content type or entity.
I believe the first option should work and that's our preference as it's the least complex. However, it strikes me that this is off-label usage and as such may have hidden 'gotchas'. Does anyone have thoughts on this?
The only issue I can think of is IF the user wanted to remain a member of both groups but change which was primary. Then we'd need to update the db with a custom update query. But if we can simply force which ever they joined first to be primary then there's no issue. If they leave the primary then the next group they joined would become primary without the site doing anything.
Anyway, if you have thoughts on this please let me know.
Thank you kindly,
Eric
Comments
I think you got it
I think you got it over-thought or thinking from the wrong perspective.
A simple way might be to use OG for all groups but have a field on user profile that references "primary group." Just use a view to limit to groups UID is a member of, then have a select list. Or leave the group reference field as open to all groups and have a rule that checks if they they are a member and joins accordingly.
Not sure how you are a handling payments but you could then use the group_reference field as the initiator of who they paypay email deposits to after you pay via the site.
Just some thoughts.
Yes, but
Thank you for the time. You are quite right about the overthink'n' - see xkcd's The General Problem!
As I understand you, you describe my second option where we'd use a field on e.g. a user profile to store the primary group id.
As I see it, storing primary group ID in a separate field is double storage because the time stamp and the table ID both already 'contain' that data. And while Rules rules, in general I'd rather shoot for a more normalized data model because there's just less to break. So if I can get away with only storing primary membership within the workings of the OG module without breaking that or my functionality, so much the better.
In this use case, whichever local club signs them up first is the club who collects their dues, etc. Only if they are no longer members of that group does it cease to be their primary group. Since I can query group membership and sort by id and or by timestamp, it would seem to me that this is a perfect fit for no additional / secondary storage.
But I am equally concerned that this is more an off-label use and I don't know what or how my function could break. If it has a chance of breaking, then I'd rather use the second option as you described.
I think it's somewhat tangential to the issue but the primary group determines whether the national club charges dues, sends them reminders, etc., or if the national club sends the local club a packet and has them charge for dues. We use it as conditions on Rules that send, notify, allow or disallow purchasing of memberships, etc.
Does this at all change your thoughts?
And in my defence, I think this is one of the very few times I'm trying not to build an arbitrary condiment passing system ;)
Eric
Definitely multiple ways to
Definitely multiple ways to solve this issue.
Since it sounds like primary membership is important, I don't see any problem in isolating it to a single field (outside of OG) via a reference. I think you are going to be make more work and more complicated integration trying to do it as you said "within the workings of the OG module."
Got it, will try to test possibilities
Got it. Thanks for the feedback.
I think you are quite right in that the field method will work. All the same, like I said, I think I'd like to see if it can be done without additional fields or rules (for syncing with group membership). If not, it's on to the fields method.
I'll do my best to report back as we get some data on whether the 'OG only' option can work and what any pitfalls may be.
Eric
i think about OG
I think I'd like to see if it can be done additional fields or rules