we are currently adding group features to our memberships.
In our case, it would be really handy, to have the same kind of relationship like with the “paidForBy” flag - but without the logic for payments - more like a “belongsTo”:
We are enabling group onboardings for memberships. There is always one “main” member. If we want/need to enable individual payments in the future also for groups, then we would loose this link to the main user by the “paidForBy” flag in fabman for the group.
In the past, we used additional packages without price or permission to recreate this connection, but this resulted in a very long list of packages without price or permission. It would be great if some new feature could solve this issue for us.
interesting idea. If you don’t use the paidForBy logic, would you use this relationship just to know that the members belong together or would you need anything more, like filter by groups, or do any actions for a whole group?
With the paidForBy relation, there is a main contact/member for the group.
We currently use this central contact/member to invoice bills for the whole company (like a fixed price / monthly for the whole group).
But other invoices, like usage of machines is paid by the individual member. So the “company field” does not solve our case, unfortunately.
Also for overview purpose, it would be nice to have all groups listed in the member search. (like with the packages, for example).