the 'member' feature

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
mixel's picture

At the moment we have members of a group. But notice its not the only place to have members. Take a project, several people participate in a project and of-course you can have projects in groups, but you can have inter-disciplinary projects as well. The common solution is to create a group for that projects, but this approach is actually reducing the principle of a group. A group are people who have a common thought. I just realized today that you could see contacts a a kind of member too: a member to your identity-space. So it may be interesting to have 'member' feature where you have a type (group, project, user) a user id an a cluster id (where the id depends on the type).

I already have talked in the managing story about a feature 'attribute' that also has the similar structure as the member structure here. There are good reasons wy I would like to treat some features similary; to make api for it. I have explained my position about using nodes for groups in an other post, but let me do it again. At this moment I think most nodes are content features while og is something else. Now some of the api can be questionable to have on a group (like the version system). My suggestion is to split the whole 'node' idea into a very generic feature 'node' having a selective part of the current functions and a subclass 'content' that expands the functions.

With 4.7 you nodes are still content (features). We could see the version id being the cluster id (in our 'member' feature). Let us expand the whole node table with one column extra called 'feature' and rename the version id to second id (or so). So every 'feature' ( content, member and attribute) would relate to a different type of second id (version, cluster, relation).

For groups I was thinking of a feature 'layer' where the second id could indicate the hierarchy (so you could have groups in groups). A group would be a feature = layer, type = group. We can do the same with a type = dyadic (contacts), type = organization, type = government. I must say I'm not fully satisfied with the layer feature and looking into it.

Knowledge sharing developers

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week