Wishlist: A Way to Track Pending Patrons after Fully Registered

[John Amundson]

Evergreen 3.2.10ish

I don't know if there is a strong desire to track this stat or if there is already a way to do so, but I could see some benefit for tracking pending patrons, (patrons who self-registered in the OPAC), after they are fully registered, (and/or deleted).

Currently when a pending patron is registered or deleted, it is fully removed from the staging.user_stage table. I cannot find any way to track what happens to the pending patron after the action is taken.

This is great from a privacy standpoint, but I can also see the potential in being able track these patrons from a statistical standpoint. I.e. How many pending patrons were turned into full records last month? How many pending patrons already had cards in the system?

This currently has to be tracked manually. Pending patrons turned into full registrations could also be tracked using specific stat cats, but staff would have to remember to enter them.

A basic solution to this would be to add a field to actor.usr called self_registration or staged_usr or ... that would read TRUE/FALSE. Patrons that were registered from the Pending Patrons screen could record as TRUE. Reports could then be run to see how many registrations were from self-registrations.

Another more in-depth solution could be to rework staging.user_stage so that it retains some form of information after a patron is deleted or registered. There is already a complete column that displays FALSE for all pending patterns in our network. I don't know if this is being used. Perhaps the column could display TRUE once the patron is registered. Another column could be added for deleted that would display FALSE/TRUE. Most identifying information could also be stripped out of the table when a patron is deleted or registered, leaving just row_id, row_date, home_ou, requesting_usr, complete, and deleted with usable data. The Pending Patrons interface could look at entries where complete=FALSE and deleted=FALSE when deciding what to display.

Creating an updated staging table could allow staff to run reports to see how many pending patrons become real patrons and how many were deleted.

[Galen Charlton (gmc)]

I lean more towards adding fields to actor.usr rather than turning the staging tables into quasi-permanent reservoirs of PII, even if they get pruned.

I say field(s) because I could envision the following in addition to a self_registered Boolean:

- self_registration_date
- imported (maybe - I'm suggesting this as a way to distinguish between self-registered patrons and patrons that were imported via a process that populates the staging table (if, in fact, anybody is actually importing patron records that way.))

[Terran McCanna (tmccanna)]

+1 to either or both of these ideas. We're currently working with Quipu to do address verification so that we can have patrons self-register for e-cards (based on Bill's work at KCLS) and we have been wondering how to track this type of change as well.

[John Amundson (jamundson)]

I definitely like the idea of recording the self_registration_date in actor.usr.

If we only add fields to actor.usr, though, then we aren't tracking self-registrations that get deleted. Does that stat matter? I'm genuinely asking because I don't know. This stat could be useful to see how efficient self-registration is. For example 80 patrons self-registered last month but only 20 were converted to full records, etc.

[Galen Charlton (gmc)]

I'm also not sure about the value of tracking deleted self-registrations, although I could imagine that doing so might help turn up UX issues with the self-registration process (or a need for more spam protection).

However, if it is worth tracking in some fashion, I would suggest creating a separate statistics tracking table so that there's no temptation do anything other than outright delete rows from stgu and friends once they're no longer needed.

[Jason Boyer (jboyer)]

Might it work to add a new OUS (or two?) to auto-apply a stat cat to users converted from pending to "real?" This would allow consortia-wide or library-specific tracking of this information and a potentially easier way to remove it should staff have cause to.

For discussion: As mentioned, this would be fairly easy for staff to remove / change; is it more important to provide flexibility or to know with certainty "forever" that a specific account was converted from staged? Another thing to consider, if the "forever" route is preferred, what to do when it comes to purging users? Copy the field or let it be lost?

Why I care: one of these options is basically a code-only change while the other would be code + database changes to a fairly major table.