Anonymization Concerns - Circ History Check Out Staff

[John Amundson]

Affects 3.9+

LP Bug #1919500 exposed Check Out Workstation and Check Out Staff to the "Circ History List" tab of Item Status.

While recorded in the database and available in reports, this is the first place I can think of that Check Out Staff is exposed client-side on circulations prior to the current.

Because this data is now exposed, we have concerns around anonymization. circ_staff is not anonymized when a circulation is aged, which is usually not an issue (and actually preferred). However, in our system, when a circulation is renewed through the OPAC or automatically, the patron's data is stored in the circ_staff field.

This means that we are showing anonymized circulations that now have links that go directly to the patron's record, which to say the least, is less than ideal.

I'm not sure the best long term solution here, but for the time being, perhaps "Check Out Staff" can display as blank if the circulation is an OPAC or Auto renewal.

[Benjamin Kalish (bkalish)]

I'm not convinced it makes sense to include the patron information under circ staff even when the renewal is from the OPAC or Auto renewal. Is there some good reason for this I am missing?

[Galen Charlton (gmc)]

Good catch, John.

I think in the long run one part of the answer will be modifying action.aged_circulation to permit circ_staff to be nullable and having the aging triggers null circ_staff when that value is equal to the loan user. The upgrade path for circulations that are already aged won't be able to be that precise, but can check on the renewal flags.

In the short term, yeah, not displaying the check out staff value for OPAC and auto-renewals makes sense.

Upon reviewing the code, we'll also need to do the same thing for the checkin_staff column, as that also gets set to the patron during OPAC and auto renewals.

Noting that not setting circ_staff and checkin_staff at all prior to a loan being aged could break reporting.

I also double-checked the aging of hold requests and there doesn't seem to be a parallel issue there, as action.hold_request.requestor is explicitly not retained during aging.

[Jason Stephenson (jstephenson)]

Would setting the circ_staff and checkin_staff to 1, the default admin user, be an acceptable compromise?

I think a db upgrade could even be worked out for the kinds of renewals that use the patron id.

[John Amundson (jamundson)]

Noting, too, that there will be some scenarios where the circ_staff or checkin_staff will be the same as the loan user, and their information should be retained. For example, if a staff record checks out an item to their own account, that is more-or-less the same as any old circulation, so circ_staff should be retained.

Perhaps circ_staff and checkin_staff should be nullified or set to 1 only in situations where auto_renewal or opac_renewal are TRUE on the associated circulation.

In response to Jason, I would probably prefer setting the fields to 1 as that would also prevent certain reports from breaking that might be inner joined on that field.

[Rogan Hamby (rogan-hamby)]

Noting that the user 1 may not be the admin. Indeed, it could be another
user. We could (not saying we should) create an anonymous -1 user in the
spirit of the -1 bib but I think making the columns nullable is the better
answer here.

On Mon, Feb 6, 2023 at 3:00 PM John Amundson <email address hidden>
wrote:

> Noting, too, that there will be some scenarios where the circ_staff or
> checkin_staff will be the same as the loan user, and their information
> should be retained. For example, if a staff record checks out an item to
> their own account, that is more-or-less the same as any old circulation,
> so circ_staff should be retained.
>
> Perhaps circ_staff and checkin_staff should be nullified or set to 1
> only in situations where auto_renewal or opac_renewal are TRUE on the
> associated circulation.
>
> In response to Jason, I would probably prefer setting the fields to 1 as
> that would also prevent certain reports from breaking that might be
> inner joined on that field.
>
> --
> You received this bug notification because you are a member of Evergreen
> Bug Wranglers, which is subscribed to Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/2001728
>
> Title:
> Anonymization Concerns - Circ History Check Out Staff
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> Affects 3.9+
>
> LP Bug #1919500 exposed Check Out Workstation and Check Out Staff to
> the "Circ History List" tab of Item Status.
>
> While recorded in the database and available in reports, this is the
> first place I can think of that Check Out Staff is exposed client-
> side on circulations prior to the current.
>
> Because this data is now exposed, we have concerns around
> anonymization. circ_staff is not anonymized when a circulation is
> aged, which is usually not an issue (and actually preferred). However,
> in our system, when a circulation is renewed through the OPAC or
> automatically, the patron's data is stored in the circ_staff field.
>
> This means that we are showing anonymized circulations that now have
> links that go directly to the patron's record, which to say the least,
> is less than ideal.
>
> I'm not sure the best long term solution here, but for the time being,
> perhaps "Check Out Staff" can display as blank if the circulation is
> an OPAC or Auto renewal.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/2001728/+subscriptions
>
>

[Michele Morgan (mmorgan)]

As a short term solution, I would add my vote to update the client display such that the patron's id is not displayed when the circ is an opac renewal or auto renewal.

Here's a branch that does that. Instead of the patron iformation, it displays an indication that the circ was either an autorenewal or opac renewal:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mmorgan/lp2001728_hide_patron_as_checkout_staff

See the attached screenshot. This approach is similar to the <Aged Circulation> indicator, also shown in the top transaction in the screenshot.

I agree that a longer term solution is needed to prevent the circ_staff field from recording the patron's id. In regards to setting circ_staff and checkin_staff to 1, it's worth noting that currently when a staff user is purged, their assets are assigned to usr id 1 unless a destination user is specified.

[Gina Monti (gmonti90)]

Working well for me! Here's my sign off on Michele's fix:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=067844745c646f04e0bd5865ac466890c23c2231

[Jane Sandberg (sandbergja)]

Thanks, Michele and Gina! Merged to rel_3_9 and above. I also opened bug 2019005 to tackle the database-level fix needed.