wishlist circ history - notify staff at checkout if item is in users circ history

Bug #1745623 reported by Josh Stompro
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Evergreen
In Progress
Wishlist
Jeff Godin

Bug Description

As mentioned by Eva Cerniňáková at http://georgialibraries.markmail.org/thread/ruonbc6g3cyz7abf, a feature that allowed staff to be notified at checkout if a title has already been checked out by a patron would be useful to have.

I agree that this feature would make the circ history useful to those that don't use the catalog.

For example, we have customers that read 3 western novels a week, in some of our smaller branches they read every title on the shelf and understandably cannot remember every title they have read previously. This feature would allow staff to help them not accidentally check out the same titles over and over again.

This potentially could also be useful for homebound patrons, where staff are selecting titles for them.

We would like to see this integrated with the web based self check also, since 70-90% of our checkouts happen at the self checks.

Josh

Tags: circulation
Jeff Godin (jgodin)
Changed in evergreen:
status: New → In Progress
importance: Undecided → Wishlist
assignee: nobody → Jeff Godin (jgodin)
milestone: none → 3.2-beta
Revision history for this message
Jeff Godin (jgodin) wrote :

We have a library that is very interested in this feature, and I'm planning to develop this in time for 3.2.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

In addition to the (I think) obvious ou setting to active this, I think there ought to be a user setting to disable it. There are some folks (myself among them) who deliberately read a book more than once. I wouldn't want the system nagging me every time I checked out an item for the second, third, or fourth time.

Revision history for this message
Andrea Neiman (aneiman) wrote :

+1 to Jason's remarks about settings, both OU and patron.

Revision history for this message
Kathy Lussier (klussier) wrote :

+1 to Jason's suggestions from me as well.

Revision history for this message
Terran McCanna (tmccanna) wrote :

+1 to this feature and to the settings

Revision history for this message
Terran McCanna (tmccanna) wrote :

To clarify: This will only be for the patrons who have opted to have their circulation history saved, is that correct? (We require patrons to opt in to store circ history, and staff do not see what the patrons' circ history is even if they opt in.)

Revision history for this message
Bill Erickson (berick) wrote :

Maybe we should ask patrons to opt in instead of making it possible for them to opt out. As Terran noted, staff are currently unable to see patron circ history. This feature will require exposing new data to staff.

In the catalog, where patrons opt in to circ history, for example, there could be a secondary checkbox for "allow staff to see if I have already checked out an item and warm me before checking it out again", except with better words.

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

The problem I have with options that require the patron to opt in from the catalog is that we have many people that never use the catalog and never will. And even if they do use the catalog, and check their account, they will never find the option to opt in unless staff are right there next to them, showing them where to click or clicking for them.

I see one benefit of this feature as making the reading history useful to those that don't use the catalog. So requiring someone to use the catalog to enable it seems like a barrier.

So I think there should also be a way for staff to control the feature to opt someone in. I'm really fine with an opt in, as long as staff can set it for the patron.

This would also allow the feature to be a question on the registration form that staff can set when creating an account.

Josh

Revision history for this message
Kathy Lussier (klussier) wrote :

+1 to opt in instead of opt out.

Users already have to opt in to maintain a reading history and will need to log in at least once to get the feature to work anyway. Bill's suggestions makes it easy for the user to provide the additional opt-in at the time they turn it on.

In the wake of Cambridge Analytica's misuse of personal information, I think people are becoming more concerned with data collection and how that date is used. Libraries should be a safe place where people can take comfort in the fact that we are not tracking more data than we need unless they explicitly ask us to maintain that data.

I would be okay with making these toggles available on the patron registration/edit form as well, but I would prefer it if there were a setting allowing sites to disable this staff-side toggles. I would support this feature going in with or without the staff side controls.

Jeff Godin (jgodin)
Changed in evergreen:
milestone: 3.2-beta → 3.next
tags: added: circulation
Revision history for this message
John Amundson (jamundson) wrote :

Noting that I, personally, am not in favor of this feature, and if it is implemented, it should be as Bill and Kathy recommend where it is opt-in and can be enabled/disabled in the OPAC.

I also think only the patron should be able to adjust their reading history settings from the OPAC and that no additional toggles be added to the Registration/Edit screens in the staff client. There is too much room for staff involvement in updating a setting when a patron really doesn't want their history tracked. If as a patron I've chosen to not keep my reading history, I do not think staff should be able to override that. I should be in control of my own data.

For patrons who don't usually use the OPAC and rely on staff, staff can still sign into the OPAC with the patron's initial password and set the settings from there.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.