Proposal: New 2.x branch rewrite based on Relation module

So, kristiaanvandeneynde, if I understand aright, Groups is basically a complete revamp of the older Organic Groups concept done up as proper Entities to make it potentially much more flexible in D7 and compatible moving forward with D8 and up. Am I right on this?

Have you looked at the powerful yet lightweight Relation module? It's basically an API and Views Integration module with little in the way of user interface (even at admin). It’s fully Entities-based — unlike Entity Relationships and the like, Relations themselves are Entities and can themselves have fields in addition to those on the endpoint Entities. The Relation module and its API go way beyond one-to-one, one-to-many, or even many-to-many relations. It allows relations to be directional or symmetrical, transitive (not actually implemented yet, but the API structure is there), any cardinality (there can be any number of endpoints in a given relationship, not just two), and so on.

Best part: creating a relationship via Relation automatically creates the reverse relationship, so making a Group a Parent of a Node automatically makes the Node a Child of the Group. This doesn’t happen with the likes of Entity Relationship. (Actually, Entity Relationship does currently provide back-reference relationships, at least via Views integration which provides relationships not only for “Children referencing Parent” but also “Parent referenced by Children” ― be careful which relationship wording you pick!)

In looking over many of the Feature Requests in this queue, it seems to me that if Groups were to be redone as being based on not just Entities but Relations as well, that many of them would be much easier to accomplish, and the whole system would become much more powerful.

Example: #2317195: Allow more than one parent by node / subgroup. That one has, as of the time I write this, 62 (now 76) Replies, many of them from you. The issue is almost 2½ years old as of this writing. Therein you say that it would be a very powerful feature but that you designed the system to have only one parent per node to get a release version out more quickly. Multiple patches were supplied to kludge it in, and apparently there is one that does a decent job. But if Groups were Relations-based, this would’ve been so much easier to implement right from the beginning.

Here’s the sort of thing that could be done with a Relation-based Group module system: Imagine a nationwide or international association of, say, vocal groups, ranging from choirs to small ensembles and quartets and trios and the like. The main organization is divided into regions or districts or whatever, and under those are chapters or churches or whatever, each of which can have one or more choruses or choirs or chorales or whatever. A chapter can also have trios or quartets that contain singers which may or may not also be members of the choir (on an individual basis). A person could be a member of a quartet and a chapter, and a given quartet could also be independent of any chapters but still under a region, or could even have members that are in multiple regions that get together for tours and contests.

Because Relations themselves are Entities and thus fieldable, the Relation of a Singer to a Quartet or Chorus Group Entity can have a Field for, say, Voice Part (in this case a Term Reference to a Taxonomy vocabulary). This way, the same Singer who sings Baritone in Choir A could also sing Bass in Quartet B. This is not the sort of thing that could easily be stored in the user’s Profile, since it could differ based on which groups s/he’s a member of.

I’m not sure if I’m using the Issue Queue the right way for something like this. Is “Plan” the correct category, or “Task”? It’s a bit more than a mere “Feature Request,” I’d think. If I did this wrong, I apologize.

(Edited to increment the version number, since it’s apparent to me that the #2317195-70: Allow more than one parent by node / subgroup in and of itself justifies a 7.x-2.x release because it introduces significant backwards incompatibilities.)

(Edited again to restore the original proposed 2.x version number since kristiaanvandeneynde has stated in #2317195-71: Allow more than one parent by node / subgroup that the plan now is to incorporate the Multiple Parent Group functionality into the release version of 7.x-1.x now that the D8 version of the node access code has been backported.)