[OPEN-ILS-DEV] Merging Patrons

[Brandon W. Uhlman]

Hi, Karen!

Thanks for your input!

The patron-exposed version of patron merging would not be generally  
useful, especially in centralized consortia with a long-standing One  
Card policy, or single site implementations. It would be more useful  
in very loose consortia, like BC Sitka, where multiple independent  
libraries issued their own cards in their own legacy systems, and then  
joined a single-system consortium and wanted to have all their cards  
and circulations managed in a single user account.

In that case, patrons would have their many barcodes and many PINs,  
and allowing them to merge their own records would reduce staff  
workload.

Certainly, staff rights merging patrons would be  
permission-restricted, and I see a very strong case for strongly  
restricting the MERGE_PATRON_RECORDS permission - but that would be  
configurable.

I would personally prefer to designate a master record rather than  
select fields from one or more records when merging, but only because  
I think the interface would be easier. :)

I don't see any trivial way to allow for un-merging either, but maybe  
I'm missing something.

This is starting to sound a little complicated, but I think that just  
means we're doing it right. ;-)

Brandon

Quoting Karen Collier <kcollier at kent.lib.md.us>:

> 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
>
>



======================================
Brandon W. Uhlman, Systems Consultant
Public Library Services Branch
British Columbia Ministry of Education
Vancouver, BC (and Lillooet, BC)

Phone: (604) 660-2972 or (250) 256-0344
E-mail: brandon.uhlman at gov.bc.ca
         brandon.uhlman at bclibrary.ca