Angular Catalog Place Hold Screen - Change to Pickup Library Not Respected

Bug #1939150 reported by John Amundson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

Observed in 3.6.x and HEAD
Google Chrome (various versions)

I'm seeing what I consider a fairly major issue on the Place Hold screen of the Angular catalog. I noticed this in a local version of 3.6 I tested earlier in the year and again today on a developer demo server I was using to test something else.

If this has been reported before, please mark this as a duplicate and point me to the bug, but I couldn't find it.

On the Angular Catalog Place Hold screen, the Pickup Location dropdown appears to populate to the appropriate org unit based on workstation, default pickup library, settings, etc. HOWEVER, if you attempt to manually update the pickup location after it populates, the change does not take. The hold will be placed, and you'll assume the the pickup location is correct, but if you go to the record's View Holds tab, you'll see the pickup location change didn't stick.

This is a fairly major issue for a couple reasons
1) It is not uncommon for staff to update the pickup location, for example if the patron has a different default location but wants or needs to pick up the title at the workstation library
2) There is no way to to tell on the Place Hold screen that the update didn't take. You don't realize it until you look at the hold itself.

Steps to replicate:
1) Sign into Evergreen with a library A workstation.
2) Find a patron whose hold preference will default to Library B (the easiest way to do this is find a patron with a default location set to Library B)
3) Follow procedure to place a hold for the patron in the angular catalog. On the Place Hold screen, note the Pickup Location defaults to Library B . Update the location to Library A or Library C. Submit the hold
4) Return to the bib record and go to the View Holds tab. Observe that the Pickup Library column shows Library B.

Tags: angular holds
Revision history for this message
Lindsay Stratton (lstratton) wrote :

I just tested this and was not able to duplicate the issue in a hosted 3.6.4 system.

1. logged in with LIB A workstation
2. From Search the Catalog, placed a hold for patron with default pickup location LIB B
3. In place hold form, I changed pickup location to LIB C and submitted the form
4. In patron view > holds, the hold pickup library is correctly LIB C
5. In the bib rec > View Holds, the hold pickup library is correctly LIB C

I repeated the process placing the hold from the patron account with the same result - the pickup LIB updated correctly.

Revision history for this message
John Amundson (jamundson) wrote :

Thanks for testing, Lindsay.

I found the fix! LP Bug #1911031

Fixed in 3.6.2

Marking this a duplicate.

Revision history for this message
Diane Disbro (ddisbro) wrote : Re: [Bug 1939150] [NEW] Angular Catalog Place Hold Screen - Change to Pickup Library Not Respected
Download full text (4.7 KiB)

I tested this in 3.6.4 and didn't see the result you describe. The new
pick-up location shows in both the patron record and the bib hold record.
Maybe this was only a problem in 3.6.1?

Diane Disbro
Pronouns: she/her
Circulation Coordinator
Scenic Regional Library
251 Union Plaza Drive
Union, MO 63084
(636) 583-0652 ext 110
<email address hidden>

On Fri, Aug 6, 2021 at 9:00 AM John Amundson <email address hidden>
wrote:

> Public bug reported:
>
> Observed in 3.6.x and HEAD
> Google Chrome (various versions)
>
> I'm seeing what I consider a fairly major issue on the Place Hold screen
> of the Angular catalog. I noticed this in a local version of 3.6 I
> tested earlier in the year and again today on a developer demo server I
> was using to test something else.
>
> If this has been reported before, please mark this as a duplicate and
> point me to the bug, but I couldn't find it.
>
> On the Angular Catalog Place Hold screen, the Pickup Location dropdown
> appears to populate to the appropriate org unit based on workstation,
> default pickup library, settings, etc. HOWEVER, if you attempt to
> manually update the pickup location after it populates, the change does
> not take. The hold will be placed, and you'll assume the the pickup
> location is correct, but if you go to the record's View Holds tab,
> you'll see the pickup location change didn't stick.
>
> This is a fairly major issue for a couple reasons
> 1) It is not uncommon for staff to update the pickup location, for example
> if the patron has a different default location but wants or needs to pick
> up the title at the workstation library
> 2) There is no way to to tell on the Place Hold screen that the update
> didn't take. You don't realize it until you look at the hold itself.
>
> Steps to replicate:
> 1) Sign into Evergreen with a library A workstation.
> 2) Find a patron whose hold preference will default to Library B (the
> easiest way to do this is find a patron with a default location set to
> Library B)
> 3) Follow procedure to place a hold for the patron in the angular catalog.
> On the Place Hold screen, note the Pickup Location defaults to Library B .
> Update the location to Library A or Library C. Submit the hold
> 4) Return to the bib record and go to the View Holds tab. Observe that the
> Pickup Library column shows Library B.
>
> ** Affects: evergreen
> Importance: Undecided
> Status: New
>
>
> ** Tags: angular holds
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: EV bug mail
> https://bugs.launchpad.net/bugs/1939150
>
> Title:
> Angular Catalog Place Hold Screen - Change to Pickup Library Not
> Respected
>
> Status in Evergreen:
> New
>
> Bug description:
> Observed in 3.6.x and HEAD
> Google Chrome (various versions)
>
> I'm seeing what I consider a fairly major issue on the Place Hold
> screen of the Angular catalog. I noticed this in a local version of
> 3.6 I tested earlier in the year and again today on a developer demo
> server I was using to test something else.
>
> If this has been reported before, please mark this as a duplicate and
> point me to...

Read more...

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.