2020-12-02 Meeting notes

Developers in Leipzig discovered that when a User record is deleted, data related to that user remains in other apps.  Examples include feesfines (accounts, payments, comments), circ-storage (loans), and Requests.  We've already established that things such as open loans or unresolved fines block the user from being deleted.  What do we do with closed items?  For fees and fines, should that historical data be transferred to a related entity that takes care of bookkeeping for the Institution that the Library belongs to.  The infrastructure for such transfers is not always in place, depending on the Library.

When an item is deleted from Inventory, does that leave data fragments? How is that handled? 

Do we need to clear out data fragments from all relevant apps, as a part of the deletion process?  RM SIG has been talking about historical data.

Patty will write up a feature request.  Maura will bring up the question to the other SIG conveners.

Data Migration group has been talking about using API tools for migrating data.  The JIRA ticket TEMP-12 is a feature request for a template for an API deletion tool.  The description there seems fairly generic, and could be applied to our User deletion feature.

Ticket UXPROD-2818 describes work done to create the backend structures necessary to do deletions from any module via the API.  There are JIRA tickets related to this one for each of several different apps.  Ticket UXPROD-2734 (Bulk APIs for Users module) is relevant to the User deletion we've been discussing.  Can we help leverage these tickets to help our deletion? 

In the tickets related to the Bulk API support, there is no mention of performance.  If we wanted to upvote the tickets, we should define our performance requirements.

The User deletion function that we've been defining requires a check for dependencies before deleting a User.  If UXPROD-2818 is intended for data migration, the check for dependencies might get in the way.  Should historical User data be loaded during a data migration?  We don't have a use case for this ticket.

Dependency checks are needed at the moment of deletion and in advance.  Can we enrich the feature request to have a dependency check without running a delete.  Enthusiastic YES.  The JIRA ticket for the UI specifies that we should stop a deletion of a User record if there are dependencies present.  Perhaps the API ticket should have a parameter to set, so that the process could delete users or just report the dependencies. 

The dev team will try working with that, and the SIG will see if it's what we want.