I'm still chewing on this idea, but here are some initial thoughts:
OG7
We have OgMembership all over the place, both for group content and users.
We have the idea that the field API will dictate what is allowed and what is not. That is, by specifying if the field is required or the field cardinality we would control how many OgMembersihps a user can have and of which type.
OG8
We already make a better distinction, and a user is a special case and OgMembership applies only to it. This already makes the API more predictable. Developers will still use good old entity reference for associating group content (i.e. non-user entities) to groups.
However, we currently still have this mix in users, where you could use OgMembership directly or work via the user's audience field a la Entity-reference.
However this duplication adds a lot of code to OG. And I'm not sure that having field API dictate the logic is still the right way. Furthermore, controlling the business logic of how many/ which type memberships can be created for a user, can be achieved without having the logic inside the field API.
Summary
Completely remove the Audience fields for users. It will remain only for a group content, as a special case of an Entity reference field -- just so we could easily find content that is related to group.
For users, our API will only deal directly with the OgMembership entity. We could fairly easily add a UI that will allow group admins to add more groups to a user, without opting to field API.
amitaibu
commented
8 years ago
I'm still chewing on this idea, but here are some initial thoughts:
OG7
OgMembershipall over the place, both for group content and users.OgMembersihpsa user can have and of which type.OG8
We already make a better distinction, and a
useris a special case andOgMembershipapplies only to it. This already makes the API more predictable. Developers will still use good old entity reference for associating group content (i.e. non-user entities) to groups.However, we currently still have this mix in users, where you could use
OgMembershipdirectly or work via the user's audience field a la Entity-reference.However this duplication adds a lot of code to OG. And I'm not sure that having field API dictate the logic is still the right way. Furthermore, controlling the business logic of how many/ which type memberships can be created for a user, can be achieved without having the logic inside the field API.
Summary
Completely remove the Audience fields for users. It will remain only for a group content, as a special case of an Entity reference field -- just so we could easily find content that is related to group.
For users, our API will only deal directly with the
OgMembershipentity. We could fairly easily add a UI that will allow group admins to add more groups to a user, without opting to field API.I believe this change will result with: