Wiping Patrons

-- This is my wipe patron information script.
-- We remove identifiying information and put standards in so that we can identify when a patron has been deleted by renaming the user.
-- This way we can reconcile historical reports with current amount and say things like 'amount x is unrecoverable because it is for deleted patrons.'
-- We remove a patron upon request if the account is in good standing but keep a lot of information for statistical reports and historical analysis but nothing that will identify a patron.
-- The first two sql updates here are what we use but you may want to consider some variants.

update actor.usr set (email,first_given_name,second_given_name,family_name,usrname,ident_value,ident_value2,suffix,day_phone,evening_phone,other_phone,active,barred,deleted,alert_message)
= (NULL,'DELETED',NULL,'PATRON',id,NULL,NULL,NULL,NULL,NULL,Null,FALSE,TRUE,TRUE,NULL) where id = 1234567;

update actor.usr_address set (street1,street2) = ('138 Lifted Lorax Street',NULL) where usr = 1234567;

-- Two things.  One, you could combine these into one statement but they're simple enough that they can run sequentially in a cron job or manually.
-- I like keeping updates to a single table but that's me, I'm conservative.

-- We only wipe individual patrons upon request but if you're looking to wipe by expiration that's a simple change to the first one.
-- If you're looking to use activity date you will also want to look at creation date to protect those created within the last three years.
-- If you have migration libraries to consider you will want to look at your data carefully and make sure you didn't migrate in from old records
-- old creation dates.  If you did you will need to either a) update those to migration dates, b) account for that in the code somehow or c) create
-- dummy activity entries for them in usr.activity.  Depending upon how you're using it you could also use the expiration date which is simpler
-- but has some significant drawbacks and may just be a plain bad idea depening upon how you're using it.

-- Also, think about alerts.  We wipe individuals so we don't worry about this but if libraries are using alerts and barred to denote patrons they
-- want to keep a record of you may want to create conditionals to skip those.

-- In these bulk update scenarios you could change the address update to just update everything that matches the name conventions and was updated today and
-- the cron could take it from there.  You could skip the today part but then that's more auditor entries and it will take progressively longer to run
-- everytime you use it.