[OPEN-ILS-DEV] Merging Patrons

[Jason Etheridge]

> 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.

Hrmm, lost, inactive, etc are just states of a card, and we can
protect it from deletion.  We can also delete users.

So let's say Patron A has library Card 1.  They accumulate some
history on that card.  The card is lost and a new card is associated
with the patron, Card 2.  Card 2 accumulates some history.

Now staff runs a report asking about or including statistics from
Patron A.   Card 1 and Card 2 are both associated with Patron A, so
the report considers the information from both cards.  Assumption:
Card 1 is never going to get re-used with another (different) patron.

> 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. :)

Now let's say Patron A is really a dupe of Patron B, which has a Card
3.  Let's say Patron B has the most complete and accurate information
on the actual person, so we want to merge A with B.  In this case, we
simply deactivate and move Card 1 and Card 2 to Patron B, and
deactivate (or delete) Patron A.

Now Patron B has Card 1, Card 2, and Card 3.  Patron A no longer
exists.  Card 3 is the active one.  Card 1 and Card 2 can still
retrieve the patron, but will do so in such a way that alerts you to
the fact that they're inactive/lost/etc.  And Patron B now has
history/statistics for everything associated with the Cards.

> 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: jason at esilibrary.com
 | web: http://www.esilibrary.com