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 [EMAIL PROTECTED] www.georgialibraries.org -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] | web: http://www.esilibrary.com