[OPEN-ILS-DEV] Merging Patrons

[Karen Collier]

----- "Jason Etheridge" <jason at esilibrary.com> wrote:
> > The problem with linking various actions to actor.cards, as I see
> it, is
> > that cards can become lost or inactive, and can even be deleted (in
> the
> > database), whereas users cannot be deleted.
> 
> Hrmm, lost, inactive, etc are just states of a card, and we can
> protect it from deletion.  We can also delete users.
> 
> So let's say Patron A has library Card 1.  They accumulate some
> history on that card.  The card is lost and a new card is associated
> with the patron, Card 2.  Card 2 accumulates some history.
> 
> Now staff runs a report asking about or including statistics from
> Patron A.   Card 1 and Card 2 are both associated with Patron A, so
> the report considers the information from both cards.  Assumption:
> Card 1 is never going to get re-used with another (different) patron.
> 
> > Additionally, it doesn't solve the inspiring problem where, by
> import or incompetence, the database has
> > multiple actor.usr records representing the same physical being. :)
> 
> Now let's say Patron A is really a dupe of Patron B, which has a Card
> 3.  Let's say Patron B has the most complete and accurate information
> on the actual person, so we want to merge A with B.  In this case, we
> simply deactivate and move Card 1 and Card 2 to Patron B, and
> deactivate (or delete) Patron A.
> 
> Now Patron B has Card 1, Card 2, and Card 3.  Patron A no longer
> exists.  Card 3 is the active one.  Card 1 and Card 2 can still
> retrieve the patron, but will do so in such a way that alerts you to
> the fact that they're inactive/lost/etc.  And Patron B now has
> history/statistics for everything associated with the Cards.
> 

In the case where there are two patron records for the same person and we're merging them, I think it would make sense to leave both active cards active.  Unless the patron is present at the time, the staff member doing the merge likely has no way of knowing which of the two active cards (2 and 3 in Jason's example above) the patron actually carries or if he uses both for some reason.  And in this situation, to the best of our knowledge, neither card 2 nor 3 has been reported lost by the patron, so we have no reason to think it's in the wrong hands or to prevent its use at checkout by making it inactive.

In terms of the interface to deal with multiple cards, I like Brandon's idea of displaying all active cards in the patron's sidebar so staff can see at a glance whether there is more than one active card.  I also like the idea of allowing staff to add a new card and activate or inactivate (in the case of lost, stolen, and found cards) any past cards as needed in the User Editor, possibly similar to the way multiple addresses are handled - displaying all addresses with a "Valid?" checkbox and a button to add another.  

In terms of merging patrons, I think Elaine made a good point about whether a merge could be undone in a case where the merge should not have happened, and if that isn't the case, making sure the person doing the merge knows this can't be undone and is asked to verify they really want to do it.  It would also be nice to be able to pick and choose which fields to take from which record in cases where the fields have different information and can't be logically combined (or to designate one record as the default at the staff person's option and skip the picking and choosing steps).  This is starting to sound pretty complicated though, isn't it?

I'm having trouble thinking of a situation where we'd want a patron to be able to merge their record to another record on their own (or where the patron would want to AND have the appropriate login info for both accounts).

My two cents.

Thanks,
Karen

Karen Collier
Public Services Librarian
Kent County Public Library
408 High Street
Chestertown, MD 21620
410-778-3636


> > On a quasi-related topic, maybe now is a good time to try and drill
> down a
> > little bit more about a piece of the DB schema that has always
> bugged me.
> 
> The DB schema is only part of the picture.  The objects used within
> Evergreen can have virtual fields that don't necessarily map to a
> column in the DB.  In this case, the Fieldmapper::actor::usr object
> (hint name "au") has two fields, one called .card and the other
> called
> .cards, a virtual field.  On a "fleshed" user object, .cards will be
> an array of all the cards linked to the user.  And .card will point
> to
> an active .card.
> 
> The current issue is that this some of the interface (and maybe some
> of the middle layer) assume that only one card can be active.  So, if
> that is not in fact true for your library, then we might need to
> develop things a bit more.
> 
> -- 
> Jason Etheridge
>  | VP, Community Support and Advocacy
>  | Equinox Software, Inc. / The Evergreen Experts
>  | phone: 1-877-OPEN-ILS (673-6457)
>  | email: jason at esilibrary.com
>  | web: http://www.esilibrary.com