[OPEN-ILS-DEV] Merging Patrons

[Brandon W. Uhlman]

Quoting Jason Etheridge <jason at esilibrary.com>:

>> Related, while there's no interface for user buckets in the staff   
>> client at the moment, there
>> is infrastructure to support them, and this would be a good way to   
>> expose merge functionality
>> to the librarian, I think.
>
> Another good place to expose this would be in the
> Patron->Other->Groups display, where folks associate users into
> groupings representing families, classrooms, etc.  I believe this
> grouping mechanism is what folks have been using in the past to link
> duped accounts.
>
>> Anyway, there are my thoughts, just off the top of my head.  Is that
>> heading toward what you were thinking of in terms of implementation?
>
> Mike, in the past, I know you were also musing using actor.cards as an
> indirect link to users in places where users are referenced.  So
, for
> example, transactions would follow the cards and not the users, and
> then, for duped users you could simply move their cards to the good
> users.  Is this still viable/desirable?

Not to answer for Mike, but yes and no. :)

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. 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. :)

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. There is a relationship in both directions between  
actor.usr and actor.card, but the relationships are different. An  
actor.usr references exactly one actor.card via actor.usr.card  
('has_a'?). An actor.card similarly references exactly one actor.usr  
(via actor.card.usr). Unlike the opposite relationship, there is no  
constraint against having multiple actor.cards referencing an  
actor.usr ('has_many'?).

There isn't even a constraint against having multiple active  
actor.cards for a given actor.usr, even though the opposite  
relationship can handle only one active card. I also recall MikeR  
telling me back in the Olde Time that having more than one active card  
per usr would be fraught with problems, though that might have only  
been because the interface wasn't exposed to manage it.

~B

======================================
Brandon W. Uhlman, Systems Consultant
Public Library Services Branch
Ministry of Education
Government of British Columbia
605 Robson Street, 5th Floor
Vancouver, BC  V6B 5J3

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