Quoting Jason Etheridge <[EMAIL PROTECTED]>:
Related, while there's no interface for user buckets in the staff
client at the moment, there
is infrastructure to support them, and this would be a good way to
expose merge functionality
to the librarian, I think.
Another good place to expose this would be in the
Patron->Other->Groups display, where folks associate users into
groupings representing families, classrooms, etc. I believe this
grouping mechanism is what folks have been using in the past to link
duped accounts.
Anyway, there are my thoughts, just off the top of my head. Is that
heading toward what you were thinking of in terms of implementation?
Mike, in the past, I know you were also musing using actor.cards as an
indirect link to users in places where users are referenced. So
, for
example, transactions would follow the cards and not the users, and
then, for duped users you could simply move their cards to the good
users. Is this still viable/desirable?
Not to answer for Mike, but yes and no. :)
The problem with linking various actions to actor.cards, as I see it,
is that cards can become lost or inactive, and can even be deleted (in
the database), whereas users cannot be deleted. Additionally, it
doesn't solve the inspiring problem where, by import or incompetence,
the database has multiple actor.usr records representing the same
physical being. :)
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.
~B
======================================
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]
