Deleting users does not delete person data (degrees, activities, etc)

[danludwig]

Found out where this was coming from. UCosmic tracks User and Person records separately. Every User must be connected to a Person, but not every Person needs to be connected to a User. So we can have People in the system who are not Users, but we cannot have a User who is not a Person.

When deleting a User, Doug had code in here to first delete the User, then delete the Person, as two separate transactions. What I believe happened here was that the User deletion transaction succeeded, but the Person deletion transaction failed. The reason that degrees, activities, etc, are showing up in the system is because that data is connected to the Person, not the User.

The correct solution here is not to delete the Person when deleting a User, but to instead disassociate them from their tenancy in the system. The Person record can be reused in other places. For example, say Halflants was a contact on a UWI agreement in addition to being a USF user. Deleting their Person record from the USF side would remove them from being an agreement contact on UWI's side, which should never happen. Instead the system should keep Halflants degrees, activities, etc in the system but disassociate them from USF. We can do this by removing their affiliations with USF and flagging them as inactive. The deletion of the user account and disassociation should also happen in a single transaction so that if one step in the process fails, the whole operation fails, without putting the data into an inconsistent state.

[danludwig]

Fixed in 62667be

Moving forward, deleting a User will disassociate the Person from the establishment that was connected to the User tenancy. All other data will remain in the system -- affiliations, activities, degrees, expertises, etc -- but will not show up in searches for these items within the previous User's tenancy context.

We still need to fix the cases where Person records were not disassociated when the User account was deleted before this fix. I believe we want to remove Corarito, but want to confirm the other users that need disassociated before doing so.

[danludwig]

After applying the above fix, I realized the problem is actually bigger than this. I was right about the 2 transaction thing -- the DELETE USER succeeded but DELETE PERSON failed, and all of the activities, degrees, and expertises are connected to the PERSON. This is why Doug, Menezes, Njoh, and Halflants were still showing up on degree searches. Doug was also showing up on activity searches, and would have shown up on the expertise searches if we had them.

When Doug designed the relationships for Activity, Degree, and both Expertise entity sets, he had them set to ON CASCADE NO ACTION. This means that if you try to delete a Person, and that Person is connected to at least one Degree / Activity / Expertise, the database will stop the whole transaction, leaving the Person undeleted. I have checked the database and all of these people except Menezes had no User account in the system. In Lynette's case she had 2 Person rows, which is what made me realize this bigger problem...

Like I mentioned above, a User cannot exist without being connected to a Person, but you can have a Person that is not connected to a User. The User entity really only keeps track of one thing, and that is the username / EPPN that is used to log into the system. When you create a new User, the current code creates a new Person row. So if you add a User, delete them, then add them again, you end up with 2 Person records in the system -- one connected to a User, the other not connected.

I would consider this a low priority for now, since we should know who is using the add & delete user pages. I have already built a query to run in production that will do the following:

1. Delete all Degrees and Person for Corarito, Njoh, and Halflants. This will remove the degrees you are currently seeing for these people, along with all of Doug's test data.
2. Delete Menezes' duplicate Person account along with its degrees. The degrees that will be deleted are the "Unknown" ones.

I can run this in production as soon as we confirm it.

As for the long-term solution to this, I think it will have to come after we do the email address thing. When creating a new User, the code should first look for an existing Person that has the same email address. We can trust email addresses coming from the USF data service and use that to prevent duplicate Person entities from being created.