> 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: [EMAIL PROTECTED] | web: http://www.esilibrary.com
