On Sat, Aug 16, 2008 at 11:41 AM, Brandon W. Uhlman
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] | web: http://www.esilibrary.com
