Hello, I just wanted to revisit this topic since I had a chance to look into the implementation side. We have discussed the “should we do this at all” on our end and have decided that it is something we want to offer. Specifically allowing staff to enable the circ history for customers. I want to thank everyone for sharing their thoughts on this issue. The feature mentioned by Eva, allowing staff to be alerted based on the users circ history at checkout was quite interesting. That would be very useful for some of our customers that seem to devour some genre fiction. I created bug #1745623 for that feature request.
It was really easy to add it, and the enabling part just works. I should mention that we are still using the XUL client, I don’t know if this works with the web client yet. The circ history is controlled by a pair of user settings, history.circ.retention_age and history.circ.retention_start. If either of those exist for a user and have a non-blank value then the circ history is kept for that user. When enabling the circ history in the catalog, only history.circ.retention_start gets set, and gets set to the current date. But the value doesn’t actually matter, it just needs to be non-blank to be considered true. To trigger that preference to show up in the patron registration screen, you need to assign it as an opt in setting type of a dummy action_trigger event definition. I just created one based on the au.created hook, but I think that any passive hook would work. The event def doesn’t even need to be enabled for it to work. I also went into the user_settings type editor and changed the label for history.circ.retention_start so that it is called “Save my Checkout History”. We might change that in the future since that label isn’t exposed to customers in the catalog to something more staff focused. After those steps the preference will show up on the patron registration screen. The sorting of it seems to be based on the hidden name of the user setting, not the label. So in our case it puts that preference first. That isn’t ideal for us, but not that big of a deal. If the preference is set by staff during registration or afterwards, it changes the value of the user setting to ‘true’. Since the circ history just needs the setting to have a non-blank value this enables it. If customers then disable the feature from the catalog, the feature gets turned off correctly and the circ history is purged like normal. When staff turn off the feature the setting gets changed to ‘false’ and the circ history isn’t purged. The setting of ‘false’ is non blank, so the history stays on. So the one scheduled change we will run daily is to look for those situations and delete the setting and delete the circ history. We will just make it clear to staff that deleting the circ history is completed overnight. In some ways this is a nice safety feature. Customers get a confirmation dialog for removing their circ history. This give staff a chance to realize they checked the wrong box and undo their change. The batch query that we will run is at https://gist.github.com/stompro/e1f3a377ee6b7e044c285b482a1e0a50 The batch process could also add extra notifications to the user about this feature being enabled or disabled. We could add a message to the message center, send an email, send a text, etc. In the future, I think the settings for enabling the circ history will be moved to a single Boolean setting, which should integrate with the staff access better. The current two settings made sense back when the circ history was looking directly at circulation transactions, but now that it is stored separately it doesn’t make as much sense. There is a comment in the circ history database function about changing it someday. bug #1745624 Josh Stompro - LARL IT Director From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Rogan Hamby Sent: Wednesday, October 18, 2017 5:06 PM To: Evergreen Discussion Group <email@example.com> Subject: Re: [OPEN-ILS-GENERAL] Reading History opt in on patron application There's a lot to think about here. I do like the idea of the setting being on the patron registration page so that staff can turn it on and off for patrons as an assistance. Actually, I think we should have had that for a long time now. If you're doing this as a local hack how you do it is certainly up to you but if it's an actual change to Evergreen code the idea of tying it to a nightly cron job unnecessary. There is a question about if older circs should get fed in but that might be tangential here and more about how the reading history works. I'm not fond of giving staff access to the history though. Staff trusted with reporter permissions can do that anyway, to the extent that you haven't aged out circulations anyway. It feels like an unnecessary threshold to cross or at least one that we shouldn't cross, on principle. It does mean that patrons that want staff to see their reading history have to go to the step of giving it in some form to the staff but I feel like that's an acceptable price to pay for privacy. But I know that some communities will probably see me as paranoid in that regard. If it was implemented I feel library options, patron toggling, protection for patron toggles, etc... would be needed. It would be it's own viper nest of issues to sort through. Rogan Hamby Data and Project Analyst Equinox Open Library Initiative phone: 1-877-OPEN-ILS (673-6457) email: ro...@equinoxinitiative.org<mailto:ro...@equinoxinitiative.org> web: http://EquinoxInitiative.org On Wed, Oct 18, 2017 at 2:44 PM, Josh Stompro <stomp...@exchange.larl.org<mailto:stomp...@exchange.larl.org>> wrote: Hello, we are running into the fact that many of our patrons that want to make use of a reading history, don’t find out about it until long after they sign up for an account. Many of these patrons are also non computer/online catalog users, so there is no chance that they would ever find the option to enable it themselves, and even if they knew about it, they wouldn’t be able to set it themselves. So they find out about it after talking with staff, and then get mad when they find out that it will only have their history starting at the point they sign up. Since they don’t use computers, they need staff to walk them through (do it for them) logging into their account and finding the option, so it would be handy if staff could just do it for them. We could set the library setting to default the checkout history to being enabled, but we really don’t want to make that decision for everyone, and then put the onus on them to figure out how to use the catalog to turn it off. So we are considering adding an opt in checkbox to the patron application, along with a user setting that staff can check, to allow staff to enable the circ history at patron registration time. The user setting being checked or unchecked would trigger a nightly process that would enable/disable the reading history for that account. In theory, this could result in a customer saying that they never signed up for the feature, saying that staff did it on their own. But since it is already trivially easy for staff to log into the catalog as a customer, it seems like that would already be a problem. (staff know what the default pin numbers are based on, or could just change the pin, a customer that never uses the catalog would never know that the pin was changed) Has anyone else done this or something like this? Is this a horrible idea? I think staff would also like to be able to access the patrons history from their staff stations, which would make readers advisory easier. “Which Louis L’Amour titles haven’t I read yet”. We have had problems in the past with patrons physically marking books that they have read before, to make it easier for them to find the ones they haven’t read. Josh Lake Agassiz Regional Library - Moorhead MN larl.org<http://larl.org> Josh Stompro | Office 218.233.3757 EXT-139<tel:(218)%20233-3757> LARL IT Director | Cell 218.790.2110<tel:(218)%20790-2110>