Good morning –


If the option of saving circ history is enabled during registration, is that 
history visible on the staff client or only on the OPAC?


Thank you.


Diane Disbro

Circulation Coordinator/Branch Manager

Union Branch

Scenic Regional Library

308 Hawthorne Drive

Union, MO     63084

(636) 583-3224




From: Open-ils-general 
[] On Behalf Of Josh 
Sent: Friday, January 26, 2018 8:48 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Reading History opt in on patron application


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


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 
[] On Behalf Of Rogan 
Sent: Wednesday, October 18, 2017 5:06 PM
To: Evergreen Discussion Group <>
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:   <>

web:   <>


On Wed, Oct 18, 2017 at 2:44 PM, Josh Stompro <> 

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 




Lake Agassiz Regional Library - Moorhead MN  <>

Josh Stompro     | Office  <tel:(218)%20233-3757> 218.233.3757 EXT-139

LARL IT Director | Cell  <tel:(218)%20790-2110> 218.790.2110  



Reply via email to