Evergreen

OPAC View for Hold Status Not Looking for Hold Shelf Delay Status

Bug #1959405 reported by Erica Rohlfs on 2022-01-28

This bug affects 7 people

Affects		Status	Importance	Assigned to	Milestone
	Evergreen	Fix Released	Undecided	Unassigned	Evergreen 3.8.1
	3.7	Fix Released	Undecided	Unassigned	Evergreen 3.7.3

Bug Description

EG version 3.7

I feel like I'm creating a duplicate bug, but I can't find this exact scenario listed.

When a library has the Library Setting Hold Shelf Status Delay set, and an item enters into this delay, the OPAC view of the Hold's Status column becomes blank.

To recreate:

1. Administration -> Local Administration -> Library Settings Editor -> search Hold Shelf Status Delay -> set the value to 1 minute or more.

2. Place a hold for a patron. The status will be "Waiting for Copy"

3. Capture the hold.
-Staff Client will display "Hold Shelf Delay"
-OPAC will change from "Waiting for Copy" to a blank/empty status column

4. Allow the delay interval to expire
-Staff Client will display "Ready for Pickup"
-OPAC will change from the blank status to "Available"

The OPAC view for the Hold Status is not looking for the Hold Shelf Delay status. There is also a conversation here as to whether the patron should just continue to see the "Waiting for Copy" status during the delay period or if they should see what staff see with "Hold Shelf Delay"

Tags:

Garry Collum (gcollum) on 2022-02-02

Changed in evergreen:
status:	New → Confirmed

Revision history for this message

Garry Collum (gcollum) wrote on 2022-02-02:

"Hold Shelf Delay" is meaningless to a patron. Another option would be to change that status to read "Processing for Hold Shelf" or something similar.

I actually fall on the side of the argument that the status should continue to display "Waiting for Copy".

Revision history for this message

Garry Collum (gcollum) wrote on 2022-02-03:

Here's a fix that continues to display "Waiting for copy"

Bootstrap:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gcollum/lp195405_Bootstrap_hold_shelf_delay_status

TPac:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gcollum/lp195405_TPac_hold_shelf_delay_status

tags:

added: opac pullrequest

Revision history for this message

Terran McCanna (tmccanna) wrote on 2022-03-18:

hold-ready.jpg Edit (67.7 KiB, image/jpeg)

I'm currently testing this and waiting for my hold shelf delay time period to pass. One thing I noticed is that although the "Waiting for copy" message does appear as desired during the delay period, the count of holds ready on the menu (in BooPAC) already indicates that it is ready. (See screenshot.)

That wasn't part of the original bug report, but I could see patrons being confused by the discrepancy.

Revision history for this message

Terran McCanna (tmccanna) wrote on 2022-03-18:

I also tested on TPAC and saw the same behavior - the bug that was originally reported is resolved by this, but the count is advanced while the text still says Waiting for copy.

So, since the fix does solve the reported bug and does improve the current behavior, I'll sign off on it and create a new bug to follow up for the count problem.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp195405_hold_shelf_delay_status_signoff

tags:

added: signedoff

Revision history for this message

Terran McCanna (tmccanna) wrote on 2022-03-18:

(Noting that bug 1427664 talks about the hold count so I won't create a new bug report.)

Michele Morgan (mmorgan) on 2022-03-23

Changed in evergreen:
milestone:	none → 3.8.1

Revision history for this message

Mike Rylander (mrylander) wrote on 2022-03-24:

Thanks, Garry and Terran! I've merged this to rel_3_7, rel_3_8, and master for 3.9. While merging, I squashed the two commits into one, adjusted the commit message to reflect that fact, and fixed one typo in the bug number.