On Sat, Aug 16, 2008 at 4:44 PM, Jason Etheridge <[EMAIL PROTECTED]> wrote: >> 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? > > I think so, yes. :) >
I agree as well. I think we're just now bumping into the problem with enough context to be able to decide what the "other visual clues" should be, and it seems that for multiple active cards, that should be "display them all." Now, I think it's still a sane cross-check to have a pointer from actor.usr.card to actor.card.id, and enforce activeness in the application. On the other hand, Jason brought up my long buried use-card-instead-of-user idea. Most of the code deals with actors, not cards, so again, heavy refactoring would be required to make things card-centric. If we did go card-centric then we would probably want to move much of the classifying data (profile_group, home_ou, probably credit_forward_balance) from the usr to the card ... which is equally difficult. Staff accounts (or rather, functions that staff-ish permissions, um, permit) make this far trickier. Much to think on, methinks. -- 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
