[OPEN-ILS-DEV] On Cards (Was: Merging Patrons)

[Brandon W. Uhlman]

I'm not a native speaker of FieldMapper, so let me try some  
translation into PostgreSQL Schema (a language I know a little better)  
and see if I get it right.

'Current card' and 'display card' are synonyms for a value in  
'actor.usr.card' referencing an actor.card record, and the only  
purpose for actor.usr.card is to indicate a record for display. Am I  
right?

In British Columbia, more of a shared system than a borrowing  
consortium, the state of having multiple active cards is not only not  
confusing, but expected in many cases. The concept of One Card to Bind  
Them is the confusing part.

In cases (not just here but in general) where a given user has  
multiple cards, I don't think we can algorithmically define any card  
as the OneTrueCard. Would it not be better to show all the cards in  
the sidebar, and indicate by colour or otherwise the card that was the  
access point to this transaction? And similarly teach the staff client  
about managing multiple cards?

None of this goes to my original question about merging user accounts,  
but your earlier responses have given me something to ruminate about.  
I'll come back with what I dreamed up.

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

I'm sure you probably explained it fine; but, like usual, it took me a  
little while to come to the party. ;-)

~B

Quoting Mike Rylander <mrylander at gmail.com>:

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



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