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

[Grant Johnson]

hmm,
Just went through this thread!
Don't know about other Academic institutions ...and don't speak for this one...and don't know if this is helpful... but...

My knee jerk response would be - There MUST be only one active card per Patron  to prevent stolen cards from being re-used by nefarious folk.

***  Apparently the above isn't a Universal Truth ***

Because we can re-issue cards, there can be multiple cards associated with a patron - done
We need to be able to set "old" cards as inactive if they are damaged/lost - done

The need to have multiple active cards might be addressed by displaying patron history, when the patron is retrieved, for all cards associated with that patron.  The interface might also  allow the setting of "active/inactive" for each card. Does it do this now?

In our case we would only EVER have one active card............ And the fun we're having makes me shudder when I think of multiple active cards. 

Cheers
-- 

F. Grant Johnson
  Systems Coordinator
  Robertson Library
  University of Prince Edward Island

>>> On 2008/08/17 at 2:00 AM, in message
<20080816220045.jb3q2vqdb4kwsws8 at webmail.bclibrary.ca>, "Brandon W. Uhlman"
<brandon.uhlman at bclibrary.ca> wrote:
> 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