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 <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
| 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: [EMAIL PROTECTED]
[EMAIL PROTECTED]
