Wishlist: Retrieve recent patrons

Bug #1709521 reported by Bill Erickson on 2017-08-09
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen circa 2.12

Goal of this bug is to make it possible for staff to receive a configured number of the most recently accessed patrons in the web staff client. In cases where the configuration supports retrieving more than one patron, a new "Retrieve Recent Patrons" menu option will be available to staff for retrieving multiple recent patrons. See http://masslnc.org/node/3308 for more details and mock-ups. This project is sponsored by MassLNC.

One modification to the original proposal is to display the recent patrons list directly in the search results page, in lieu of a dedicated interface, sorted by most recent at the top.

Bill Erickson (berick) wrote :

Code with release notes pushed:


To test:

1. Apply a value of > 1 to the new 'ui.staff.max_recent_patrons' library setting.
2. Navigate to the patron search interface, search, and select/view several patrons.
3. Click the new 'Retrieve Recent Patrons' Circulation menu action.
4. Confirm a list of patrons displays in the patron search UI, sorted most recent first, showing no more than the configured maximum.

Test 2

1. Delete the library setting 'ui.staff.max_recent_patrons' and confirm the 'Show Recent Patrons' action disappears from the interface.

Test 3

1. Set the value for the 'ui.staff.max_recent_patrons' to 0 and confirm both the 'Show Recent Patrons' and 'Show Last Patron' menu items are not visible.

tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.0-alpha
assignee: Bill Erickson (berick) → nobody
Kathy Lussier (klussier) wrote :

Bill, I'm getting merge conflicts on this branch. Would you be able to resolve them? Thanks!

Kathy Lussier (klussier) wrote :

Thanks Bill! This looks good. I noticed just one issue. The release notes say the new setting will default to 1 for backwards compatibility. However, it doesn't look like this is being set to 1 in the upgrade script or in the seed data. It defaulted to null in my testing.

Bill Erickson (berick) wrote :

Hi Kathy, when no OUS value is applied, the UI code falls back to using a value of 1. I had originally considered applying an OUS value of 1 globally during the upgrade, but this seemed cleaner. Did you have functionality problems or were you more concerned about it causing confusion? Thanks.

Kathy Lussier (klussier) wrote :

Hmmm...when I first upgraded and left the setting with a null value, the 'retrieve last patron' option wasn't visible in the menu. I just set it back to null, and it's falling back to 1 as expected. I'll look at it again Monday and report back if I see the same behavior that I saw when first upgrading.

Kathy Lussier (klussier) wrote :

I'm guessing that in my previous testing, I actually set a value for the setting, unset it again, and then forgot to refresh the cache. It all works as expected now. I signed off on the branch and added a commit to update the setting description to clearly identify what the default # of patrons is if it is left unset.

To give others uninvolved in this project an opportunity to look at it, I've pushed my signoff to the working repo at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/lp1709521-retrieve-recent-patrons-rebase-signoff

If nobody else looks at it by the end of the week, I'll merge it.

Thanks Bill!

Cesar V (cesardv) wrote :

I tested this today, and it works fine.

One thing I did want to suggest was to consolidate the 2 menu options, that way avoiding having two options on the menu that essentially do the same thing... and only differ in how many patrons are retrieved...

Set it up so that instead of having 2 similar possible menu items, make it so that depending on the value of the library setting, the menu item changes dynamically to show up only once if the settings value > 1 and shows in plural (i.e "Retrieve Recent Patrons"), or if value == 1 uses the "/circ/patron/last" (unless that API is to be deprecated), or if value == 0 doesn't show up at all.

Bill Erickson (berick) wrote :

Thanks for review and testing, Cesar!

I considered making a similar suggestion about collapsing the 2 patron retrieval commands into one. The rub is that even if a library configures the setting to be > 1, they may still want to use the (singular) "retrieve last patron" action, since unlike the plural version, it jumps directly to the patron in question (instead of a list). So for libraries with a setting value > 1, we're adding an extra double-click to retrieve the most recent patron.

It's possible this is not such a heavily used feature that an extra double-click really matters. Anyone care to weigh in on Cesar's suggestion of showing only the (plural) "Retrieve Recent Patrons" option when the setting is > 1?

Kathy Lussier (klussier) wrote :

Thanks for the feedback Cesar! Bill's comment about the extra double-click is exactly on point as to why we requested the two separate menu options with this project. Our staff liked the way the current "Retrieve Last Patron" menu option works, with it immediately retrieving the patron record. They didn't want to lose that quick access to the last patron. Based on my discussions with folks, I do think that feature gets a lot of use in our libraries.

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
Jason Etheridge (phasefx) wrote :

Looks good to me, thanks folks! Pushed to master

Changed in evergreen:
status: New → Fix Committed
assignee: Jason Etheridge (phasefx) → nobody
Jason Etheridge (phasefx) wrote :

Just one thing occurs to me (after the fact); do we want to just rely on documentation/training to distinguish between org unit settings that only affect the web client vs those that affect just the xul client vs those that affect both?

Kathy Lussier (klussier) wrote :

That's a good question. It might not be a bad idea to put a branch together that updates the description for those OU settings that only work in one client.

Bill Erickson (berick) wrote :

I'll open a new bug for this if needed, but posting here for now, a patch to fix an issue where last/recent patron values are not set when patrons are retrieved from the checkout (retrieve patron by barcode) UI.

In short, the patron service now loads the setting directly instead of requiring the calling UI to set it.


Kathy Lussier (klussier) wrote :

Thanks Bill! It works for me. The values are now set when retrieving patrons via barcode and when retrieving from a patron search. I've merged your fix to master.

Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers