U4-4005 - Member custom properties not saving from code, only from backend

Created by Josh Olson 08 Jan 2014, 14:33:30 Updated by Shannon Deminick 16 Jan 2014, 09:20:33

When saving custom member properties using member.Save() in code, value is pseudo-saved. The new value is visible in the backend but cannot be retrieved in code until the save button is again clicked in the backend. See the following post for more details: http://our.umbraco.org/forum/umbraco-7/using-umbraco-7/47270-U7-Members-Member-custom-property-saving-mirage?p=0#comment169299

Comments

Dima Stefantsov 09 Jan 2014, 22:53:52

I believe entire nForum is falling apart because code like m.getProperty("forumUserLastPrivateMessage").Value = DateTime.Now; doesn't work. Is there some better modern api to work with Members properties?


Mikkel Johansen 10 Jan 2014, 00:07:56

Looks like it everytime you use member.Save(). Not only when changing custom properties.

I have tried to test it - see code below. First I get a Member and outputs it. Then changes Login and EMail, and saves the member. Then I get the member again and outputs it. But the properties is the same . Looking in the back-end the changes is visible. @inherits Umbraco.Web.Mvc.UmbracoTemplatePage @using umbraco.cms.businesslogic.member @using Member = umbraco.cms.businesslogic.member.Member

@{ Layout = null;

// Remember to create Member in Backend
// Member: Login = test, E-mail = test@test.dk
    
Member m = Member.GetMemberFromEmail("test@test.dk");
@ShowMember(m)

m.LoginName = "Test1234";
m.Email = "newtest@test.dk";

m.Save();

Member testMember = Member.GetMemberFromEmail("newtest@test.dk");
@ShowMember(testMember)

}

@helper ShowMember(Member member) {

Name: @member.Text
LoginName: @member.LoginName
E-mail: @member.Email

}


Josh Olson 10 Jan 2014, 07:41:23

Dima, I would love if there was a better modern api to work with Members properties! Cheers to that!


Dima Stefantsov 10 Jan 2014, 10:03:40

Josh, a little googling suggested it will be - in 7.0.2, we probably can hope for it :)


Sebastiaan Janssen 10 Jan 2014, 11:31:14

Can reproduce, have assigned to Shannon to be fixed asap :)


Shannon Deminick 13 Jan 2014, 06:46:27

The problem is due to some caching logic. The legacy member API slightly wraps the new members API (which is still a work in progress - to be released with 6.2 and 7.1) but the API wrapping is not complete. This must have been an oversight from late last year. I'll fix up in 6.2 which will merge into 7.0.2


Brian Parks 14 Jan 2014, 18:49:02

Shannon, any chance we can get a patched 7.0.1 release that contains this fix? This is a critical fix for us and unfortunately our project timing won't allow us to wait for 7.0.2. Thanks for your consideration.


Josh Olson 14 Jan 2014, 19:24:02

I would second that motion! I can't find any mention of a release date for 7.0.2, but I am going to guess it is probably past my project deadlines also!


Sebastiaan Janssen 14 Jan 2014, 19:36:10

Nightly builds are available here: http://nightly.umbraco.org/umbraco%207.0.2/

You could also opt to make your own build. v7.0.1 was built off of revision 6a5a320a22da709b4216a7292e257242928b7151 and the fix for this issue can be cherrypicked from revision e74e8f9d731d30b8c973e8db21c8167f5fda7cd8


Josh Olson 14 Jan 2014, 19:44:46

Thanks Sebastiaan.


Brian Parks 15 Jan 2014, 07:56:53

I was able to get this working by applying the necessary changes to the 7.0.1 source -- seems to be working fine.

I attempted to use 7.0.2 nightly binaries (build 237), but there was an issue with the Membership provider: System.Web.Security.Membership.ValidateUser() was returning true for invalid passwords (works fine with 7.0.1 binaries). I didn't dig into the source to find the cause, just a heads-up to whomever is working on that.

Thanks again for providing the quick fix, Shannon.


Shannon Deminick 15 Jan 2014, 08:19:16

Cool, i'll re-open this to remind me to look tomorrow at the provider, has lots of tests against it so seems strange. will see if i can repro.


Shannon Deminick 16 Jan 2014, 09:20:29

Good find, the logic slightly changed with membership refactoring in 6.2, all good now.


Priority: Critical

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.0.1

Due in version: 7.0.2

Sprint:

Story Points:

Cycle: