U4-4255 - Add readonly membership provider properties to the profile model

Created by Shannon Deminick 18 Feb 2014, 22:44:27 Updated by Shannon Deminick 25 Mar 2014, 23:27:14

Subtask of: U4-1659

The profile model that gets exposed with the members helper should have readonly values for the membership provider properties instead of just showing up as normal content properties.

Comments

Barry Fogarty 25 Mar 2014, 11:35:07

in v6.2 beta and RC, the attributes e.g. umbracoCommentPropertyTypeAlias="comments" umbracoLastLoginPropertyTypeAlias="lastLogin" umbracoApprovePropertyTypeAlias="isApproved" umbracoLockPropertyTypeAlias="isLocked" do not map to the relevant properties on the Member type.

For example I now have 2 'Approved' properties on my Member Type, my custom property (isApproved) and the readonly property (umbracoMemberApproved). My custom property is ignored when validating the user and only the value of the internal umbracoMemberApproved property is interrogated.

NB Member site upgraded from 4.7.


Shannon Deminick 25 Mar 2014, 23:19:07

Hi,

There were some changes from 6.2 beta to 6.2 RC, see:

http://issues.umbraco.org/issue/U4-4227

If you want to continue using the 6.2 beta - you'll need to re-run the installer from the previous version you upgraded from. If it was 4.7, then change your version back to 4.7 in your web.config and re-run the installer. This should execute the migrations that are new in 6.2 RC that were not in 6.2 beta.

I'm not sure what you mean by "My custom property is ignored when validating the user" - how are you 'validating the user' ?

Please note that all the new membership controllers/snippets/IMember model/etc... are all based on conventions in that the member properties must be named according to our conventions. When you save a MemberType which does not contain these properties, it will create them but you'll note that you cannot remove these property types or change their data type's since they need to exist with all new membership logic and must be the correct data type.

Of course if you want to keep your old properties then you'll have to continue using members in the legacy way - the same way you were using it in 4.7 - that should all work the same way. Can you verify that is the case?

The last issue that I've just noticed is if you want to migrate all of your legacy property's to the new conventional ones. We'd have to write a script to do that, I'll make a note of that with the core team.


Shannon Deminick 25 Mar 2014, 23:27:14

Have you changed to use the new membership provider by chance? If so, it is 100% based on the new membership stuff and your property types would need to be named based on the convention so you should continue using the old membership provider with your custom mappings. If you want to use the new one, you'd have to map your old property values to the new conventional ones.


Priority: Normal

Type: Task

State: Fixed

Assignee:

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions:

Due in version: 6.2.0

Sprint:

Story Points:

Cycle: