[OPEN-ILS-DEV] On Cards (Was: Merging Patrons)
Brandon W. Uhlman
brandon.uhlman at bclibrary.ca
Sun Aug 17 01:00:45 EDT 2008
Quoting Mike Rylander <mrylander at gmail.com>:
> On Sat, Aug 16, 2008 at 4:44 PM, Jason Etheridge
> <jason at esilibrary.com> 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.
I think we might mean different things when we think of 'enforcing
activeness'. I hear that and think, 'only allowing use of actor.cards
with the active flag set to true'. Do you mean something else?
The sane cross-check part, I still think I disagree with, unless I'm
missing something. With multiple intentionally active cards on a
record, which one should we refer to in actor.usr.card? The first one?
The most recent one? What if the card we refer to is marked inactive?
Do we pick one of the remaining ones as active? If so, how? It all
seems like an exercise in randomness to produce a value we only ever
use for display, anyway. And if we go ahead and display all of them,
as we appear to have agreed on, then we don't even use it for that.
~B
======================================
Brandon W. Uhlman, Systems Consultant
Public Library Services Branch
British Columbia Ministry of Education
Vancouver, BC (and Lillooet, BC)
Phone: (604) 660-2972 or (250) 256-0344
E-mail: brandon.uhlman at gov.bc.ca
brandon.uhlman at bclibrary.ca
More information about the Open-ils-dev
mailing list