[OPEN-ILS-DEV] Merging Patrons

Mike Rylander mrylander at gmail.com
Sat Aug 16 09:03:29 EDT 2008


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


More information about the Open-ils-dev mailing list