Full name gets reseted to i:0#.f|fbamember

I don't know - it looks like there's some type of timer job happening on your installation.  The FBA Pack doesn't install any timer jobs, so i'm not sure where it's coming from. 

If you're interested, you can pick up a support plan and we can do a screen sharing session - i'll take a look at your environment:

http://www.visigo.com/purchase.html

It cannot be a timer job, the ItemUpdated gets triggered. It has to be an item in the list.
Also, why do we get the "Status" column does not exist.
And why when this exception raise the name gets reset?

I cannot give any access of some sort on this environment.

Other information I can give you is that the users that get reseted dont have a "User information" page. The page that is opened when you on the user name in a list (Created By).

It wasn't manually deleted. So I cannot say if it doesn't exist because of the bug, or the bug occur because of this.

Did you delete the list using SharePoint Designer before redeploying, as was mentioned earlier? If you have, I don't know why you'd be getting the exception. I also have no idea why ItemUpdated would be triggered if Review Membership Requests is off. And it looks like the update is happening via a timer/scheduled job of some sort, otherwise I wouldn't expect the source to be OWSTimer.exe.

You can always try a clean installation on a different machine and see if you run into the same issues.

It's strange they don't have a user information page - but I don't see that causing any of these issues with the FBA Pack.  It's more that it shows that there's probably other issues with your environment.

I deleted the list from SP directly (Site Actions->Site Settings->FBA Membership Request Management then delete the list normally. Is something different happening if I didn't delete it from SPD?

I see in the error says OWSTimer, but in a event, that you created in your list handler, is not very likely to be triggered by a timer job you didn't create.

I have an environment which has the FBA and we were unable to reproduce the problem. I'm not even able to reproduce the problem on the prod environment for other users than the 2 that have been suffering the problem.

I'm still puzzled on which line of code is resseting the user name when the exception occur.



I’ve had the issue with resetting the names from alerts created in SharePoint on any list (Not just membership request) – not sure why it happens.
As for deleting the list from the List Settings, that should be fine too.
The event should be triggered any time any item is updated on the list, by whatever process.

I have an alert on a list and the problem didn't happen (Membership request is uncheck however).

I know the event can be triggered any time by an updated item by whatever process. But the list is empty, and what process is "Adding" an item in that list so the event trigger.

No idea. I'd look into the rest of your environment. Maybe remove the list, undeploy the FBA Pack and see if you still get OWSTimer errors (They should be different now, as there's no list to update, but i'd think you'd still get the error).

If I undeploy the FBA pack, I shouldn't be getting the exception anymore, since the list doesn't exist. I'll try this.

Hi ccoulson,

So I finally found a bug in the FBA pack that could explain the exceptions I find in my logs and that might cause the Full name reset like me and other people have.

In your "MembershipReviewList" you have "MembershipReviewHandler". If you look at its Elements.xml you register this Receiver on the ListTemplateId 100.

<Receivers ListTemplateId="100">

However the ListTemplateId 100 is a Generic Type in SharePoint.

http://techtrainingnotes.blogspot.ca/2008/01/sharepoint-registrationid-list-template.html

What happen is whenever a item in a list that is from the ListTemplateId 100, your event received trigger. That's why we see the "Column status not found...".

The proper way to fix this is to change the "Type" value in the ListTemplate, the "TemplateType in the ListInstance and of course the ListTemplateId in the Receiver to a custom value of yours. Something unusual of course, like "23231". This way the ItemUpdated will only trigger when items of MembershipReview are updated.

 

Now on WHY the fullname gets reset, I still don't know. But since the exception that raise at the same exact moment than the fullname (Exact day/hour/minute/second) gets resets, I highly suspect that this is responsible.

 

 

That makes sense! Actually - there's already an issue raised for that - fix will be in the next version:

http://sharepoint2010fba.codeplex.com/workitem/772

Great. I'm still wondering why the fullname gets reset.

Dunno. I've put a note on the issue to look into that when i'm fixing - to see if it's that event handler causing the issue - or if it happens with all alerts.

Since I don't need the Membership Review I'll put all the code in comments in the event receiver for the weekend to see if this is responsible for the name reset.

Good idea. Let me know the result.

Not sure if it's a bad luck again, but the problem didn't happen since I deployed my custom version with the event handler code commented.

Good to hear!