tpac: can't reactivate or change activated date for a hold through the edit hold interface

Bug #1004638 reported by Kathy Lussier
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Undecided
Unassigned
2.3
Fix Released
Undecided
Unassigned

Bug Description

Evergreen version: 2.2 RC1

In My Account, a patron can suspend a hold by clicking to "edit" the hold, selecting the option to suspend it, and (optionally) setting an activation date. However, once the hold is suspended, there is no option through the edit holds interface to reactivate the hold or to change the activation date. The only way to manually re-activate the hold is to use the "Actions for selected holds" menu.

This is problematic for a couple of reasons. If the user suspended the hold through the "edit holds" interface, it is reasonable that they would assume they would need to take the same path to re-activate the hold.

Once the hold is suspended, there doesn't seem to be a way for a patron to change the activation date without re-activating the hold through the "Actions for selected holds" menu and then suspending it again through the "edit holds" interface. I could see a common scenario where the patron uses the wrong date format for the suspended hold. Once submitting the the form, the user is likely to immediately see that the date isn't displaying and then might be likely to try adding the date again by clicking the "edit" link. However, the only option now available for the suspended hold is a change in pickup library.

Revision history for this message
Kathy Lussier (klussier) wrote :

It looks like the code was hiding the activation options for holds that were already captured since we don't want users suspending holds that are already in transit or on the holds shelf. However, we were inadvertently hiding these options for suspended holds at the same time.

user/kmlussier/lp1004638 will display the activation options for suspended holds.

tags: added: pullrequest
Changed in evergreen:
milestone: none → 2.2.1
Revision history for this message
Lebbeous Fogle-Weekley (lebbeous) wrote :

Works great! Thanks Kathy. I'm merging this to master and rel_2_2, so it will indeed make 2.2.1.

Changed in evergreen:
status: New → Fix Committed
Revision history for this message
Lebbeous Fogle-Weekley (lebbeous) wrote :

Just noticed that the commit had the sign-off in the wrong place. It went into master that way, although I fixed it before pushing to rel_2_2.

git-commit's -s option usually does the right thing, but I'll watch out for this in the future.

Changed in evergreen:
status: Fix Committed → Fix Released
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.