U4-6366 - Issue assigning member roles on MemberService.Saved event

Created by Andrew Ellis-Chadwick 05 Mar 2015, 11:45:49 Updated by Warren Buckley 14 Mar 2016, 15:16:18

Performing this action:

memberService.AssignRole(member.Id, "role name");

on the Saved event of a member, does not persist the data to the db, it seems to get rolled back.

2 Attachments

Comments

MrFlo 04 Dec 2015, 16:33:39

Same for me on this and all the Values of custom properties are null... https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/73380-member-saved-event#comment-235467


MrFlo 04 Dec 2015, 16:37:02

Another problem is when you try to get the e.Entity.Name is the login returned not the actual Name of the member...


Marcin Zajkowski 04 Dec 2015, 16:37:45

I also had this problem. Done some workaround using property as flag to check if it was overrided and then set my desired property once again on save, but this is just workaround. Bug is still a bug.


Michel Collard 28 Jan 2016, 11:35:41

This issue was posted on 05 Mar 2015 12:45 and is still not fixed in the newer Umbraco versions.
The version I noticed this bug in is: 7.3.1.


Shannon Deminick 28 Jan 2016, 22:01:01

You cannot save in the creating event, that is not supported and not intended to be done. This event simply is there to prepopulate and entity with values.

If you want to force a value before saving, you use the saving event, just set the property value and it will get saved... Again, do not attempt to save the item in this event since its already In the pipeline to be saved.


Michel Collard 04 Feb 2016, 15:52:24

@Shandem Thanks for your reply. However I am not trying to add a property, but I'm assigning a Role using the memberservice in the Saved event. This role is not persisted in the database:

memberService.AssignRole(member.Id, "role name");

Tried the Created and Saving event also, but no luck.


Shannon Deminick 04 Feb 2016, 16:17:53

Ok, i'll try to explain again:

These events are used to modify the Model - that's it.

  • During Created, you can modify the model which will be used to display the new item in the UI back office of Umbraco, this is the only reason you should use Created.
  • During Saving you can modify the model just before it gets persisted - during this event it is already on it's way to being persisted.

Do not ever attempt anything with the member service during these events because what you are doing there is trying to persist data during the data persistence routine which you cannot do.

The Saved event is after persistence has occurred, so here, you 'could' execute persistence logic but in normal circumstances you wouldn't do this because you can modify the model just before it's saved by Umbraco. There's no point in saving something twice.


Shannon Deminick 04 Feb 2016, 16:26:27

Perhaps this unique circumstance with the member roles has an issue, i'm not sure but this logic would only work using the Saved event. Since the IMember object does not hold references to it's roles, you cannot just modify that collection during the Saving event. I don't see why memberService.AssignRole(member.Id, "role name"); wouldn't work in the Saved event for a member. Maybe it's a cache issue? If you do that and then restart your web app, is the member now in that role?


Michel Collard 05 Feb 2016, 10:48:28

Thanks for the information. I know that I can not use the Created and Saving event for this purpose but tried everything possible.

I do not think it is a cache issue. I tried assigning a member role(that already existed) in the Saved event. But no luck. Like the issue description says, In the database I noticed that a new row was being created in the [cmsMember2MemberGroup] and after the code is done the new row just disappears.


Andrew Ellis-Chadwick 05 Feb 2016, 11:45:38

@Shandem I want to assign some users values only if i know that the user has been successfully created.

Things that would be unique cross site and if the uses is not created for some reason i don't want to generate the value in the fist place.

So the "Saving" event is not a guarantee that the user is in the system where as in the "Created" event i know the user is then in the system and i can generate my unique values.

Which is surly what the created event is for ?

Hope that make sense.

Also it is strange that when you debug and step through it that the value is set in the Database during the created event and then removed after the created event is finished.


Shannon Deminick 05 Feb 2016, 12:59:05

Hi, i'll need to review @Michel 's issue next week.

@Andrew.Ellis-Chadwick The 'Created' event is absolutely not doing what you expect it is doing. The 'Creating' event has been obsoleted for some time because the Created event did the same thing. This is NOT when the object is created in the database, this is simply when a new Model is "Created" to give to the back office UI. It has nothing to do with persistence - we will be removing this event in v8 since it makes no sense. The ONLY reason you would use this event is to pre-populate values on a model so the content editor sees these values before they press save to actually save the item to the db. "Saving" is not a guarantee the user is in the system, you can inspect this by looking at the ID of the entity. "Saved" does guarantee the user is in the system, this executes after the database has submitted it.


Andrew Ellis-Chadwick 05 Feb 2016, 13:05:02

@Shandem That makes more sense :) thanks


Shannon Deminick 10 Mar 2016, 14:54:37

This is fixed in rev: 11f9cdead02359ad931ec0cc8d744dfaffee133f

@Michel this will fix your issue. The problem was that in the Member editor (UI), it was performing it's role additions/deletions after the member was saved. I've changed it now to lookup the members current roles before saving the member so that new ones added with events are not removed afterwords.

To test, use this code in an application started handler:

MemberService.Saved += (sender, e) =>
            {
                foreach (var saved in e.SavedEntities)
                {
                    sender.AssignRole(saved.Id, "asdf");
                }
            };

Then go save a member in the back office, you should see that they get assigned a role of asdf


Warren Buckley 14 Mar 2016, 15:16:18

I can confirm when running a build from the nightly branch with this fix now in & with the code snippet supplied above the Role/Member group is persisted correctly from the event, setting as fixed.


Priority: Normal

Type: Bug

State: Fixed

Assignee:

Difficulty: Normal

Category: Extensibility

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.1.4

Due in version: 7.4.2

Sprint: Sprint 11

Story Points:

Cycle: