Re: [OPEN-ILS-GENERAL] Evergreen 3.1 Release Update

[Josh Stompro]

Dan, I’m curious if your comment coverage counts the Opensrf method 
documentation?  The   “__PACKAGE__->register_method(“ signature/notes => info?

I’ve noticed that sometimes those are very 
complete
 with a description, notes, parameter dos, and return value docs, while others 
are very 
basic.
  That might be another aspect of the code documentation to evaluate and work 
on if someone is adding comments to a specific file.

Josh Stompro - LARL IT Director

From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Daniel 
Wells
Sent: Thursday, January 25, 2018 11:28 AM
To: Evergreen Discussion Group 
Subject: [OPEN-ILS-GENERAL] Evergreen 3.1 Release Update

Hello all,

We are now entering the busy period of the release cycle, so I would like to 
take a moment to highlight a variety of efforts underway for the 3.1 release.

1) We are about two weeks away from "feature slush", currently set for Feb. 9.  
What does this mean?  To quote from our "versioning" wiki page it means: "major 
planning for features is complete; at this point, all significant features 
should either have been merged or at least have LP bugs and pullrequests".  Of 
course, the nature of slush is that it isn't very solid, so there is still some 
flexibility at this stage, but if this deadline isn't met, chances of getting a 
new feature into the release begin to diminish considerably.  Please take note!


2) We are one month from feature freeze for 3.1 (Feb. 23).  Updates to the 
roadmap continue to come in:
https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.1

For example, an interesting new entry was added last week regarding more search 
improvements (https://bugs.launchpad.net/evergreen/+bug/1744385).  Thank you, 
MassLNC and Equinox!

To everyone, please continue to add to, update, and revise the roadmap 
throughout the feature slush period.


3) As part of my release goal to improve documentation and understanding for 
new developers, I have done some basic comment analysis of our Perl services 
code, and created a sign up matrix for anyone wishing to help nudge things 
forward.  For more explanation, or to sign up, please see here:
https://docs.google.com/spreadsheets/d/17XCFAxuLvYKdjk4uDhlzzAZC28AGyQV3vugTnBXBtzg/edit?usp=sharing


4) Bill Erickson in late December published his first set of notes regarding a 
transition from AngularJS to Angular:
https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angular5

Moving fully over for 3.1 was always a stretch goal, but I think simpler 
changes like Bill's proposal to switch to Webpack are very doable in this 
release to help smooth the way.  Thank you, Bill!


5) I have made a first pass at making sure the roadmap and the related bugs in 
LP are in sync, and also getting various bugs to their proper tags and targets. 
 To help us all make use of LP more effectively, Remington and I have also made 
notable progress in getting usable results out of LaunchPad's web API, and are 
experimenting with generating simpler views as a release "dashboard" of sorts 
(nothing fancy at this stage).  We hope to have something to show in the next 
week or so; please stay tuned.


6) Not directly 3.1 related, but worth mentioning as general release news.  For 
the last point-releases, we did an initial trial run of using a signup sheet 
for splitting build tasks among the buildmaster volunteers.  It is basic, but I 
do think it will help spread the load over time.  You can see that sheet here:
https://docs.google.com/spreadsheets/d/1gZayHfF7qK0zwLMEAXt-PbKBMiAM_F6EZguqzIYceBY/edit#gid=0

It is never too late to help out with builds; just join the ##eg-release 
channel on FreeNode and make some noise, and we'll find you a seat.


Sincerely,
Dan

Re: [OPEN-ILS-GENERAL] Reading History opt in on patron application

[Josh Stompro]

Hello Diane, this doesn’t change how the circ history can be accessed.  It is 
still only available in the catalog when a customer logs into their account.  
It just allows staff to enable the feature in the patron registration screen, 
or patron edit screens.

Josh Stompro - LARL IT Director

From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Diane 
Disbro
Sent: Friday, January 26, 2018 9:52 AM
To: 'Evergreen Discussion Group' 
Subject: Re: [OPEN-ILS-GENERAL] Reading History opt in on patron application

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
www.scenicregional.org



From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh 
Stompro
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 
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 func

Re: [OPEN-ILS-GENERAL] Reading History opt in on patron application

[Diane Disbro]

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

www.scenicregional.org

 

 

 

From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh 
Stompro
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 
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 
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

Re: [OPEN-ILS-GENERAL] Reading History opt in on patron application

[Josh Stompro]

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 
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, o