I'm working on a project where we have 2 types of users "Members" and "Artists". For "Members" we are just collecting basic information, but for "Artists" we call the same basic info plus some additional peices of info. My initial though was to create 2 member types, with the different properties and then also create a group for each. I then started thinking, it should be possible that a "Member" can upgrade to become an "Artist". Now as I understand it, the member types work in a similar way to document types for nodes which I know there is no way of changing their type after creation.
So my question is this. Say I went with this approach and a "Member" wants to upgrade to be an "Artist", can you change their member type? Or should I be creating one member type, and limiting what fields they have access to based upon their role? (I'm looking for the best practise approach really, as we are expecting this app to have many users, so I want to make sure I choose the right approach).
You are correct, member-types are the same as document-types. Once you create a member, you can't change their member-type!
There are a couple of ways to tackle your problem:
Duplicate the "Artist" fields for the "Member" (along with another field for "upgraded", so you can distinguish them).
Develop code to upgrade a "Member" to an "Artist", meaning that you would create a new member (based on the "Artist" member-type) and copy across the original "Member" data ... then delete the original member. Obviously this may knacker any other business logic you may have that deals with member Ids?
I think I would go with the role based approach so you have a tab with "Member" info, and one with "Artist" info, and then decide which fields to show based on the groups they are members of.
Alternatively, if you don't want to clutter your membertype, then you could just have the basic info in there, and get the profile data from somewhere else (custom db table). This would probably scale a bit better if you decide to add more groups in the future which all need different info on them.
To answer the original question: I guess the safe way would be to copy the members from one memberType to another, and then delete the original member via the Umbraco API. In version 8 the following code should work:
Can you change a members MemberType?
Hi Guys,
I'm working on a project where we have 2 types of users "Members" and "Artists". For "Members" we are just collecting basic information, but for "Artists" we call the same basic info plus some additional peices of info. My initial though was to create 2 member types, with the different properties and then also create a group for each. I then started thinking, it should be possible that a "Member" can upgrade to become an "Artist". Now as I understand it, the member types work in a similar way to document types for nodes which I know there is no way of changing their type after creation.
So my question is this. Say I went with this approach and a "Member" wants to upgrade to be an "Artist", can you change their member type? Or should I be creating one member type, and limiting what fields they have access to based upon their role? (I'm looking for the best practise approach really, as we are expecting this app to have many users, so I want to make sure I choose the right approach).
Many thanks
Matt
Hi Matt,
You are correct, member-types are the same as document-types. Once you create a member, you can't change their member-type!
There are a couple of ways to tackle your problem:
Cheers, Lee.
Hmmm, I guess you could go with the second option, and on the entity store "PreviousID" or something so you can tie any data back to the new entity?
Matt
I think I would go with the role based approach so you have a tab with "Member" info, and one with "Artist" info, and then decide which fields to show based on the groups they are members of.
Alternatively, if you don't want to clutter your membertype, then you could just have the basic info in there, and get the profile data from somewhere else (custom db table). This would probably scale a bit better if you decide to add more groups in the future which all need different info on them.
To answer the original question: I guess the safe way would be to copy the members from one memberType to another, and then delete the original member via the Umbraco API. In version 8 the following code should work:
The code below is copied from the following repo: https://gitlab.com/umbracohowto/ourumbraco7497
is working on a reply...