I have a strange issue. I've deleted a member. This member was related to a certain membergroup. Now when I do
MemberGroup.GetByName(WebsiteMemberAlias).GetMembers(); I'll get the error that node 1077 (which is the deleted member) could not be found. Anyone has a fix/tip or work arround for this?
I think you just found a bug. I've ran into something similar a few days ago, but I was unable to reproduce it.
I think there's still a 1077 linked somewhere in the DB. You'd probably have to check the DB to see if there still is a reference to that ID somewhere.
Have to look into some db tables... cmsMember, cmsMember2MemberGroup (should be deleted there as well), and think umbracoNode as well (should also be deleted)?
How did you delete the member, I'd expect that when you delete one it should remove everything to do with that member, including the member groups.
On another note it'd be nice to see people using the ASP.NET Membership methods to access member stuff, this is more than possible via Role.FindUsersInRole (http://msdn.microsoft.com/en-us/library/system.web.security.roles.findusersinrole.aspx).
This will be the supported way of doing it going forward, particularly with Umbraco 5
Have looked at the code, it should do that, just listed tables that needs to be checked in order to find a clue about what is going wrong. Maybe a look at the umbracoLog table might also reveal something (altho not sure what to expect there).
Agree with Aaron, we should definitely focus on using membership methods and move away from the member class and the like.
@Aaron, would it be a good idea to mark those functions as obsolete? Or, if possible, mark classes as internal? Could that make it in v4.1?
The problem is fixed now thanks Aaron. I can't look into tables because I don't have access to the database. I was lucky to view the error from the Logtable by using the logviewer package. Otherwise I would never found the issue.
Dirk - for backwards compatibility in 4.1 I can't change their access modifier but I will do my best to make them obsolete. I want to really clean up the way things are accessed, Members, Nodes, etc, kind of draw the user into the primary location for getting that back.
Another thing on the cards is writing up wiki documentation on how to work with members, but it requires this thing called free time and I'm yet to find a torrent for that :P
Membergroup.GetMembers throws error when a member is deleted
Hi,
I have a strange issue. I've deleted a member. This member was related to a certain membergroup. Now when I do
MemberGroup.GetByName(WebsiteMemberAlias).GetMembers(); I'll get the error that node 1077 (which is the deleted member) could not be found. Anyone has a fix/tip or work arround for this?
Thanks,
Richard
I think you just found a bug. I've ran into something similar a few days ago, but I was unable to reproduce it.
I think there's still a 1077 linked somewhere in the DB. You'd probably have to check the DB to see if there still is a reference to that ID somewhere.
Have to look into some db tables... cmsMember, cmsMember2MemberGroup (should be deleted there as well), and think umbracoNode as well (should also be deleted)?
/Dirk
How did you delete the member, I'd expect that when you delete one it should remove everything to do with that member, including the member groups.
On another note it'd be nice to see people using the ASP.NET Membership methods to access member stuff, this is more than possible via Role.FindUsersInRole (http://msdn.microsoft.com/en-us/library/system.web.security.roles.findusersinrole.aspx).
This will be the supported way of doing it going forward, particularly with Umbraco 5
Have looked at the code, it should do that, just listed tables that needs to be checked in order to find a clue about what is going wrong. Maybe a look at the umbracoLog table might also reveal something (altho not sure what to expect there).
Agree with Aaron, we should definitely focus on using membership methods and move away from the member class and the like.
@Aaron, would it be a good idea to mark those functions as obsolete? Or, if possible, mark classes as internal? Could that make it in v4.1?
Cheers,
/Dirk
Thanks guys,
The problem is fixed now thanks Aaron. I can't look into tables because I don't have access to the database. I was lucky to view the error from the Logtable by using the logviewer package. Otherwise I would never found the issue.
Thanks again.
Richard,
Dirk - for backwards compatibility in 4.1 I can't change their access modifier but I will do my best to make them obsolete. I want to really clean up the way things are accessed, Members, Nodes, etc, kind of draw the user into the primary location for getting that back.
Another thing on the cards is writing up wiki documentation on how to work with members, but it requires this thing called free time and I'm yet to find a torrent for that :P
is working on a reply...