[OPEN-ILS-DEV] Merging Patrons

[Hardy, Elaine]

I think it would be very beneficial to be able to merge patron records,
particularly in a large consortium like PINES. But it would need to be
very tightly controlled -- more so than merging bib records. This is
particularly important since so many libraries send their delinquent
patrons to a collection agency. While accidentally merging disparate bib
records can have some negative public relations implications (if one of
those books is checked out and becomes overdue, for example), merging
incorrect patrons could have serious public relations repercussions. I
can only image the problems if a patron with large fines and many
overdues was incorrectly merged on to the record of someone with no
fines or overdues. Of course, one of the reasons there are duplicate
patron records is that patrons are trying to escape their fine history
and give various name forms and addresses when applying for a new card. 

I guess my suggestion would be to make it a little harder than merging
bib records -- more places to verify information, more places to have to
say "yes, I really do want to merge". And a way to restore the original
records if you do make a mistake. Maybe even a note on the newly merged
record indicating it was merged on a certain date (that would help
trouble shooting). 

 Elaine
________________________________

 
 
J. Elaine Hardy
Library Services Manager - Collections & Reference
Georgia Public Library Service,
A Unit of the University System of Georgia
1800 Century Place, Suite 150
Atlanta, Ga. 30345-4304
404.235-7128
404.235-7201, fax
 
ehardy at georgialibraries.org
www.georgialibraries.org
 

-----Original Message-----
From: open-ils-dev-bounces at list.georgialibraries.org
[mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of
Rylander, Mike (External)
Sent: Saturday, August 16, 2008 9:03 AM
To: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] Merging Patrons

On Fri, Aug 15, 2008 at 9:42 PM, Brandon W. Uhlman
<brandon.uhlman at bclibrary.ca> wrote:
> Hi, all.
>
> Is there a best practice for merging two patron accounts which, in
> actuality, represent the same person? I took a look around docgen.xsl
for an
> OpenSRF method that obviously exposed such functionality, but nothing
seemed
> apparent.

There's nothing today.  For a full merge, there are /lots/ of places
to update, and some things that would need very particular attention.
Based on a simple scan* of the IDL, I see 79 fields across many tables
that would need updating, though I'm certain that there unaccounted
fields, and that some are on inherited tables that can be done all in
one go, so that's not The(tm) number.  It may also be reasonable to do
this in a stored procedure for speed reasons.  Merging permissions
between two users would be complicated, to say the least, so that may
be a special case where you get the permissions for the target of the
merge (the user record you're keeping).

>
> If there's nothing extant, I could through down some thoughts on the
> process, get some feedback, and see if I could implement something
OpenSRF-y
> that would allow us to expose the process to the user -- either staff,
or
> the enduser, depending on feedback.
>

I think this is a great idea.  Having a backend method capable of this
would make certain classes of migration (wink, wink, nudge, nudge)
easier, since user merging could be a secondary cleanup process that,
like bib merge, just takes a target and a list of subordinates to
absorb.

Putting a permission constrained wrapper around such a method is a
fairly simple matter -- just require an additional first parameter of
an auth token and check that the associated user has the, say,
MERGE_USERS permission at all of the home_ou's of the candidate merge
list (loop over the candidate users and check the requesters
permissions at their home_ou).  Doing it this way would allow one to
expose it to patrons, if that is reasonable.  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.

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?


* egrep -n '(has_a|might_have)' Open-ILS/examples/fm_IDL.xml|grep
au|grep id

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone: 1-877-OPEN-ILS (673-6457)
 | email: miker at esilibrary.com
 | web: http://www.esilibrary.com