[OPEN-ILS-DEV] Merging Patrons

[Mike Rylander]

On Sat, Aug 16, 2008 at 11:41 AM, Brandon W. Uhlman
<brandon.uhlman at bclibrary.ca> wrote:
[snip]
>
> 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.
>

Actually, this seems to be a problem of terminology.  Let met attempt
to define some of the working terms in an abstract sense ...

 *  Card -- a record representing a physical identifier for a user
having a unique barcode
 *  Active Card -- any card record that has its 'active' field set to true
 *  Inactive Card -- the inverse of Active Card, any card  that has
its 'active' field set to false
 *  Current Card -- the specific card pointed at by a user record
 *  Display Card -- a synonym for Current Card

Say you have a user record which might need to represent several
issued cards (though that's not easy to do via the staff client
today), or you want to issue multiple cards to a single group account
for whatever reason, such as restricting and binding the circulation
policies of a set of cards.  Or perhaps you want to have shared staff
accounts, but you want the accountability of individual login or
override markers in the logs.  This is all just off the top of my
head, but none of these are /from/ my head.  They've all been brought
up by others as desirable functionality.

In any case, we originally saw no reason to restrict users to exactly
one card, nor, in fact, to remove the ability to add multiple active
cards to an account.  But, because you often want to see "the" barcode
for an account, and as it stands today you'd only have one active card
on an account if everything is done through the staff client
(replacing deactivates the old card), there needs to be a OneTrueWay
to get /some/ barcode and say "this is the barcode we'll display for
this user record" ... again, without restricting the future expansion
into more than one card per user.

The problems of a user with more than one active card are entirely
caused by the fact that staff wouldn't understand it without training.
 They don't expect multi-card functionality, and we haven't had a
high-priority request for it in the staff client, so the "Add Another
Card" function hasn't yet made it in.  When it does there will have to
be other visual clues that alert the staff to why the barcode they
scanned is not the barcode in the user sidebar.  But, hopefully, that
will be a simple thing.

That's the design, at least.  I'm sure that I didn't explain it well
to Brandon at the time ... sorry B!  Anyway, does that help?

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone: 1-877-OPEN-ILS (673-6457)
 | email: miker at esilibrary.com
 | web: http://www.esilibrary.com