Hi, Karen!
Thanks for your input!
The patron-exposed version of patron merging would not be generally
useful, especially in centralized consortia with a long-standing One
Card policy, or single site implementations. It would be more useful
in very loose consortia, like BC Sitka, where multiple independent
libraries issued their own cards in their own legacy systems, and then
joined a single-system consortium and wanted to have all their cards
and circulations managed in a single user account.
In that case, patrons would have their many barcodes and many PINs,
and allowing them to merge their own records would reduce staff
workload.
Certainly, staff rights merging patrons would be
permission-restricted, and I see a very strong case for strongly
restricting the MERGE_PATRON_RECORDS permission - but that would be
configurable.
I would personally prefer to designate a master record rather than
select fields from one or more records when merging, but only because
I think the interface would be easier. :)
I don't see any trivial way to allow for un-merging either, but maybe
I'm missing something.
This is starting to sound a little complicated, but I think that just
means we're doing it right. ;-)
Brandon
Quoting Karen Collier <[EMAIL PROTECTED]>:
In the case where there are two patron records for the same person
and we're merging them, I think it would make sense to leave both
active cards active. Unless the patron is present at the time, the
staff member doing the merge likely has no way of knowing which of
the two active cards (2 and 3 in Jason's example above) the patron
actually carries or if he uses both for some reason. And in this
situation, to the best of our knowledge, neither card 2 nor 3 has
been reported lost by the patron, so we have no reason to think it's
in the wrong hands or to prevent its use at checkout by making it
inactive.
In terms of the interface to deal with multiple cards, I like
Brandon's idea of displaying all active cards in the patron's
sidebar so staff can see at a glance whether there is more than one
active card. I also like the idea of allowing staff to add a new
card and activate or inactivate (in the case of lost, stolen, and
found cards) any past cards as needed in the User Editor, possibly
similar to the way multiple addresses are handled - displaying all
addresses with a "Valid?" checkbox and a button to add another.
In terms of merging patrons, I think Elaine made a good point about
whether a merge could be undone in a case where the merge should not
have happened, and if that isn't the case, making sure the person
doing the merge knows this can't be undone and is asked to verify
they really want to do it. It would also be nice to be able to pick
and choose which fields to take from which record in cases where
the fields have different information and can't be logically
combined (or to designate one record as the default at the staff
person's option and skip the picking and choosing steps). This is
starting to sound pretty complicated though, isn't it?
I'm having trouble thinking of a situation where we'd want a patron
to be able to merge their record to another record on their own (or
where the patron would want to AND have the appropriate login info
for both accounts).
My two cents.
Thanks,
Karen
Karen Collier
Public Services Librarian
Kent County Public Library
408 High Street
Chestertown, MD 21620
410-778-3636
> 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.
The DB schema is only part of the picture. The objects used within
Evergreen can have virtual fields that don't necessarily map to a
column in the DB. In this case, the Fieldmapper::actor::usr object
(hint name "au") has two fields, one called .card and the other
called
.cards, a virtual field. On a "fleshed" user object, .cards will be
an array of all the cards linked to the user. And .card will point
to
an active .card.
The current issue is that this some of the interface (and maybe some
of the middle layer) assume that only one card can be active. So, if
that is not in fact true for your library, then we might need to
develop things a bit more.
--
Jason Etheridge
| VP, Community Support and Advocacy
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: [EMAIL PROTECTED]
| web: http://www.esilibrary.com
======================================
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: [EMAIL PROTECTED]
[EMAIL PROTECTED]
