wishlist: Place Holds for Patron Buckets

Bug #1838995 reported by Andrea Neiman
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Lynn Floyd

Bug Description

This work will expand Patron Buckets to allow for the creation of "Hold Subscriptions".

The new type of Patron Bucket will allow a staff user with the correct permissions to add and remove patrons from the bucket, as well as place title-level holds for all bucket members on a particular bib. Holds will be randomized.

Patrons will be able to see their membership in Hold Subscriptions and remove themselves from said, if desired.

Full specifications can be seen here: http://yeti.esilibrary.com/dev/public/techspecs/place_holds_multiple_patrons.pdf

This work is based on requirements put forth by the Consortium of Ohio Libraries, and is being coordinated by OhioNET. Funders include:

Community Library (Sunbury)
Georgia PINES
Evergreen Indiana
Consortium of Ohio Libraries (COOL)

Public branch forthcoming.

Revision history for this message
Mike Rylander (mrylander) wrote :

The branch implementing this is available at: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1838995-hold-subscriptions

From the release notes and main commit message:

This feature allows staff to add multiple users to a named hold subscription
bucket and place title-level holds for a record for that entire set of users.
Users can be added to such a hold subscription bucket from either the patron
search result interface, via the Add to Bucket dropdown, or through a dedicated
Hold Subscription interface available from the Circulation menu. Adding new
patrons to a subscription bucket will require staff have the PLACE_HOLD
permission.

Holds can be placed for the users in a subscription bucket either directly from
the normal staff-place hold interface in the embedded OPAC, or by supplying the
record ID within the subscription bucket interface. In the latter case, the
list of users for which a hold was attempted but failed to be placed can be
downloaded by staff in order to address any placement issues. Placing a
subscription bucket hold will requires staff have the MANAGE_BATCH_HOLDS
permission, which is new with this development.

In the event of a mistaken subscription hold, staff with the MANAGE_BATCH_HOLDS
permission will have the ability to cancel all unfulfilled holds created as
part of a subscription hold event.

A link to the title's hold interface is available from the list of subscription
hold events in the dedicated subscription hold interface.

tags: added: pullrequest
Andrea Neiman (aneiman)
Changed in evergreen:
milestone: none → 3.5-alpha
Revision history for this message
Blake GH (bmagic) wrote :

Mike,

I'm installing the patch for the feedback fest. Noting here that the sql upgrade script has the ID hard coded for permission.perm_list which is in conflict with a pre-existing ID number (612 = ADMIN_CAROUSEL_TYPE on master today). Changing the patch to ID 620 (next available on master today)

The other ID's for the other tables are not in conflict.

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

Adding needsrepatch tag because of the ID number.

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

(Thanks to Dawn for finding this.)

Placing a single hold from the catalog works well, but if you place a hold from a basket that has multiple titles in it, it only places the hold on the first title. To recreate problem:

1. Create a hold subscription and add patrons to it.
2. Do a catalog search and add several titles to the basket.
3. Go to Basket Actions > Place Holds.
4. Choose the Hold Subscription and Submit.

The response only acknowledges that a hold was placed on a single title. No reference is made to the other titles that were in the basket. Go to the Hold Subscription interface, and it verifies that only one title was placed on hold.

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

Usability issue when adding a new patron to a subscription from the hold subscription interface:

It is not clear that after you scan a patron's barcode, that you then have to follow that up by clicking the "Add All to Subscription" button.

Ideally, just scanning the patron barcode would add it to the subscription without having to take that second step.

If that can't be done for some reason, and the button has to be clicked, then the button should at least be in a more intuitive location, such as to the bottom-right of the grid to follow common web practices.

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

Wording:

- Suggest changing the tab title from "Hold Events" to something more user friendly such as "Holds"

- Suggest changing the button and modal title "New Batch Hold Event" to something more user friendly such as "Place New Batch Hold"

tags: added: needsdiscussion
Revision history for this message
Mike Rylander (mrylander) wrote :

Hi Terran,

Re comment #4, being able to place a subscription hold from within the basket hold interface wasn't actually intended for this development -- it requires more thought about warnings and restrictions and such -- so I'll be hiding all that soon.

Re comment #5, it simply works just like all the bucket interfaces, with an interstitial pane for collecting a set of potential additions, and the buttons are all in the same positions.

Re comment #6, my issue with the suggestion as provided is that we're not talking about holds here, but a whole set of holds embodied by a new "thing". I considered "Hold Subscription Event" or "Hold Subscription Placement Event" but those seemed overly verbose.

I've force-pushed a master-rebased, updated branch that addresses the basket hold issue and adjusts the permission ID. As noted in the comment next to the permission addition line in the upgrade script, the eventual committer is requested to adjust this as necessary, which is common for our project.

Likewise, the baseline schema has not been updated with the contents of the DB upgrade script yet. Once there's a signoff for the code and DB changes, I'll be happy to reincorporate those, or work with whoever wants to commit the branch to do so.

Thanks, all!

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

Noting that the original spec did not call for placing multiple holds across multiple baskets (the scenario in comment #4), though that would be an interesting enhancement.

We'll look at a way to constrain the feature so people can't do the impossible though :) (and also look at the ID conflict).

Changed in evergreen:
milestone: 3.5-beta → 3.5.0
milestone: 3.5.0 → 3.next
Revision history for this message
Mike Rylander (mrylander) wrote :

Hi all,

I've pushed up a branch that rebases hold subscriptions and adds the baseline schema changes (with an updated permission id). New branch at: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1838995-hold-subscriptions-rebase

Revision history for this message
Mike Rylander (mrylander) wrote :

Hi all,

Terran, I've pushed another commit to the rebased branch to change the terminology used in the interfaces. The code (and URLs) remain as they were, but now everything is called a "Hold Group" or a "Hold Group Event" in any labeling, and the permission is called MANAGE_HOLD_GROUPS.

Thanks!

Revision history for this message
Michael Dziabiak (mdziabiak) wrote :

Testing feature for sign-off.

Changed in evergreen:
assignee: nobody → Michael Dziabiak (mdziabiak)
Revision history for this message
Terran McCanna (tmccanna) wrote :

There was a merge conflict when applying this to current master - could use a rebase.

tags: added: needsrepatch
Revision history for this message
Mike Rylander (mrylander) wrote :

I've force-pushed a master-rebased version of this branch to the same location. The conflict was on updated terminology regarding the pub flag on buckets.

tags: removed: needsrepatch
tags: removed: needsdiscussion
Revision history for this message
Ruth Frasur Davis (redavis) wrote :

When adding a user to a holds group, I was able to add duplicate patrons. Only one instance of these duplicate patrons is displayed (per user) in the grid, but the full count of user accounts (including duplicates) is displayed in the "current user" tab counter. This affects the number of holds placed when creating a hold event.

In my test, seven users were added to the hold group #1: test holds group (this is on the Mobius bugsquash server). Two of those user were duplicates so only five showed up in the "current users" grid.

When creating a new hold event for DbID 92, seven holds were placed.

Changed in evergreen:
assignee: Michael Dziabiak (mdziabiak) → nobody
Revision history for this message
Mike Rylander (mrylander) wrote :

Hi Ruth,

What path were you taking when you added duplicate users? This sounds very familiar and I thought I'd addressed this issue already.

Thanks in advance!

Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Revision history for this message
Ruth Frasur Davis (redavis) wrote :

Mike - some notes. I'm in the process of retesting this to recreate the path. In the process...

Using bugsquash.mobiusconsortium.org/eg/staff with multiple log-in setups. In this case "admin@BR1-isl_rfrasur"

There is no way to create a "hold group" from the patron search interface. There is only the "add to bucket" option. With that option, however, I can add people to existing hold groups.

Now at admin@SYS1-isl_rfrasur
In the Holds Group interface, in "Current Users" tab > Hold Groups menu > [only one user group is visible: #4: holds with 14 users counted in the tab and description but only 13 displaying; my assumption being that there is a duplicate patron]

In Holds Group interface > "Hold Groups" tab > all 3 hold groups appear and can be accessed by double clicking. Double clicking "test holds group (#1)" opens that holds group in the "Current Users" tab with a count of 7 but only 5 users displayed.

In Holds Group interface > "Hold Groups" tab > Double click "Ruth's Hold Group (#2)" opens that holds group in the "Current Users" tab with a count of 10 but only 7 users displayed.

Revision history for this message
Mike Rylander (mrylander) wrote :

I've pushed a squashed, rebased, and updated branch to https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1838995-hold-groups-squash_and_rebase that includes fixes for excluding duplicate additions to user buckets in two more places.

Revision history for this message
Mike Rylander (mrylander) wrote :

And now I've updated the above branch with BooPAC support for hold groups.

Revision history for this message
Mike Rylander (mrylander) wrote :

And, finally, staff-side BooPAC support is there.

Changed in evergreen:
assignee: Mike Rylander (mrylander) → nobody
Andrea Neiman (aneiman)
Changed in evergreen:
milestone: 3.next → 3.7-beta
Revision history for this message
Mike Rylander (mrylander) wrote :

Andrea helpfully pointed out a couple things that got lost in a rebase earlier, and one remaining instance of "subscription" that needed to become "hold group". I've pushed two commits the the above-linked branch to address those.

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

Mike,

Some of the underlying code in Open-ILS/web/js/ui/default/staff/circ/patron/app.js has changed and is causing a conflict with current master. Could you please rebase this?

Thanks!

tags: added: needsrepatch
Revision history for this message
Mike Rylander (mrylander) wrote :

Hi Chris,

I've rebased and squashed this to:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1838995-hold-groups-rebase-2021-02-10

FWIW, I believe the recent "serialize batches" work is where the conflict came from, and I adopted the current in-master pattern.

Revision history for this message
Dawn Dale (ddale) wrote :

I have tested this code and agree to signing off with my name, Dawn Dale, and my email, <email address hidden>.

tags: added: signedoff
Andrea Neiman (aneiman)
tags: removed: needsrepatch
Revision history for this message
Chauncey Montgomery (montgoc1) wrote :

I went through documentation and confirm that everything in this feature works as described, save placing holds from the catalog, viz., the new staff catalog.

Holds can be placed, as described using the traditional catalog, but when I am in the new staff catalog and click, "Place Hold," I don't see the option to place a hold for a patron Hold Group. Perhaps I overlooked where that is located in the new staff catalog.

Otherwise, everything works as described in the documentation.

Revision history for this message
Mike Rylander (mrylander) wrote :

Hi Chauncey,

You didn't overlook this in the new catalog -- the branch has been waiting for merge since long before that in. Features in that catalog will be catching up with the traditional for a while, even features that are waiting for initial merge, in some cases!

Thanks for testing!

Revision history for this message
Chauncey Montgomery (montgoc1) wrote :

I have tested this code and consent to signing off on it with my name, Chauncey Montgomery, and my email address, <email address hidden>.

Galen Charlton (gmc)
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
status: New → Fix Committed
Revision history for this message
Galen Charlton (gmc) wrote :

Pushed to master for inclusion in 3.7. Thanks Mike, Dawn, and Chauncey.

Since this originally predated the Angular staff catalog, the Angular place hold form does not yet know about hold groups. I'll file a new RC-blocker bug about that; Equinox commits to having that resolved well before the beta.

Revision history for this message
Galen Charlton (gmc) wrote :

The new bug is bug 1918183.

Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
Lynn Floyd (lfloyd)
Changed in evergreen:
assignee: nobody → Lynn Floyd (lfloyd)
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.