I have a client with this issue using DMM in 15.0.3. I checked the stored procedure and ran a few queries and find this user had values in GroupMember for these groups: iMIS15 and EventUser, plus one for the company that he is linked to (which is the association).

This user used to be a casual user. They they retooled their staff and this person became a public user. But it would seem that once he's in a group, always in a group! I have unlinked his user credentials entirely on both records, but still it refuses to merge. If I relink him to his original credentials, they come up as Casual - even though I've changed them to public several times.

So do I need to delete these groups via script? Or how else do I resolve this? Thanks!

Jennifer Strawn
Accounting & Association Software Group

We found a problem purging users (using DBRepair) which isn't detected and can result in the same behavior.

DBRepair looks for references to users in hundreds of tables before it lets you try to delete from UserMain, but it doesn't check UserMain itself!  So, if the user was responsible for creating another record in UserMain, or if it is the last record to update another record, the purge won't happen quite right.

Oddly enough, the record *will* be purged from the system, but the FK from UserMain to itself will not be recreated.

The fix I found was to overwrite any orphaned values in UserMain.CreatedBy or UserMain.UpdatedBy with the UserKey for MANAGER.

Groups are a funny thing -- many of the stock groups are automatically assigned based on criteria we are not privileged to know.  I wouldn't suggest removing any groups, but removing from GroupMember and GroupMemberDetail on behalf of this user would be worth a try.  (Remember Step 0, of course.)
--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

Hi Bruce - Thanks for your comments. I know ASP is the latest and (supposedly) greatest thing, but it is situations like this where I find myself wistfully remembering a simpler life - when all we had to consider was Name_Security and Name_Security_Groups. All this excessive complication is for the better, right?? My favorite part of your response was "criteria we are not priviledged to know". We must not be in the right group!

I guess I was focused on groups because they have been using DMM without issue and I can only assume that some of those records had credentials. What makes this situation different is that this was a former casual user, who apparently was in groups I have never heard of! I will give your suggestions a try.

The whole thing is enough to make me want to enable the stinkin' delete button in the Customer Portfolio! And I hate the delete button!! :-)

Jennifer Strawn
Accounting & Association Software Group

No problem.

The groups situation is mostly an ASI thing, and I think a good one.  This has the potential to really help us out with things we used to do in Committees OR Security_Groups OR access keywords OR relationships, but now all in one place.

The "criteria" comment was more about the magical, mystical reasons why users are automatically added to groups.  My hunch is that all full/casual users automatically go in the iMIS15 group, or maybe even full/casual/public.  I bet you could figure out the rules if you spent enough time tracing things back, but who has that time anymore?

All in all, the new security stuff (UserMain linking to aspnet_Membership and so on) seems "new", but not terribly different.  You still have people, and people have attributes, and the software controls what the people can do or see based on those attributes.  It's stored in a different set of tables and uses better security practices, but otherwise is just a bigger, badder version of what we already know.

I have my head-scratching, phone-cursing, blind-siding days too, but I remember enough of dealing with iMIS C/S 3.32 and iMIS LAN that I'm much happier to be where we are, overall.
--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

Hi Bruce - You're right. As a general rule, even the documenation for iMIS has vastly improved, but then you run across something like this and are like, huh?? I had to laugh about your LAN comment. Every time I see an ASI announcement about a patch release for LAN I just shake my head. Talk about a trip in the wayback machine. Oi. Then again, if it meets the need...

Jennifer Strawn
Accounting & Association Software Group