You can't, members have the same underlying design as documents. Why do you want multiple member types per member? Maybe you can use member roles to solve it.
Cheers Slace that is what I thought. One of the member types has encrypted information in it (subscribers and volunteers with volunteers holding personal info).
What is the best way to do a conversion between member types and what is the process?
Wouldn't a custom data type be able to hold the data you require?
If you really want to achieve it you need to programmatically delete and then recreate the member with a different member type each time. That could have problems with maintaining if the member is logged in or not.
The code wasn't wrote by me so I am just trying to get it working. The way this is implemented is:
1. We have subscriber (legacy) & volunteer Member Types (MT) 2. We have subscriber group and volunteer group Member Groups 3. Subscriber (MT) doesn't have any extra required properties other than the default 4. Volunteer (MT) has a couple of properties that need encrypted, we have a custom datatype for this but does it not only apply to the admin section?
When I looked at this originally I was going to make the subscriber (MT) have the extra properties and I even created a custom data type that done the encrypt/decrypting. Does this sound about right?
The only reason to have different member types would be so that you can have drastically different properties between each member and then roles to havedifferent operations per user.
ASP.Net's membership model isn't designed to have multiple profiles (member types), at least not quite the way we need it to use it. Roles are much better suited to that task.
For the standard Umbraco API you can get the member type from a member's ContentType property.
Given that you can't have a member of 2 types, actually creating multiple member types seems to be a trap to avoid.
As soon as you have two member types you have the possibility of a person being both.
Can a member have multiple member types?
I assume they can't am I right?
If so what is the best approach to convert a member from one member type to another?
B
You can't, members have the same underlying design as documents. Why do you want multiple member types per member? Maybe you can use member roles to solve it.
Cheers Slace that is what I thought. One of the member types has encrypted information in it (subscribers and volunteers with volunteers holding personal info).
What is the best way to do a conversion between member types and what is the process?
Wouldn't a custom data type be able to hold the data you require?
If you really want to achieve it you need to programmatically delete and then recreate the member with a different member type each time. That could have problems with maintaining if the member is logged in or not.
The code wasn't wrote by me so I am just trying to get it working. The way this is implemented is:
1. We have subscriber (legacy) & volunteer Member Types (MT)
2. We have subscriber group and volunteer group Member Groups
3. Subscriber (MT) doesn't have any extra required properties other than the default
4. Volunteer (MT) has a couple of properties that need encrypted, we have a custom datatype for this but does it not only apply to the admin section?
When I looked at this originally I was going to make the subscriber (MT) have the extra properties and I even created a custom data type that done the encrypt/decrypting. Does this sound about right?
Thanks again for the help.
On a side not how do you get the member type from a member?
The only reason to have different member types would be so that you can have drastically different properties between each member and then roles to havedifferent operations per user.
ASP.Net's membership model isn't designed to have multiple profiles (member types), at least not quite the way we need it to use it. Roles are much better suited to that task.
For the standard Umbraco API you can get the member type from a member's ContentType property.
Thanks Slace
Given that you can't have a member of 2 types, actually creating multiple member types seems to be a trap to avoid.
As soon as you have two member types you have the possibility of a person being both.
is working on a reply...