[Koha-bugs] [Bug 34972] Canceling a waiting hold from the holds over tab can make the next hold unfillable

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34972

--- Comment #1 from Emily Lamancusa <emily.lamancusa at montgomerycountymd.gov> ---
It looks like the immediate bug is in GetOtherReserves in C4::Reserves.
GetOtherReserves is written as though it should update the matched hold to be
either waiting or in-transit, but it doesn't actually do so - it ends up just
assigning the itemnumber. There are three possible scenarios here:

a) The matched hold was already found. The same itemnumber as before is set.
Status is unaffected. Result: nothing changes, and the hold was already in the
correct state to begin with. No problem.

b) The matched hold was an item-level hold. The same itemnumber as before is
set. Status is unaffected. Result: nothing changes, and the hold remains in a
valid state. No problem (unless the caller was expecting the hold to be Found,
in which case that would be a separate bug).

c) The matched hold is the highest-priority, unassigned bib-level hold. The
itemnumber is set. Status is unaffected. Result: a specific item is now
assigned to the hold, but the hold is not Found (e.g. waiting, in-transit, or
in processing). The bib-level hold has been unintentionally converted to an
item-level hold with no notification and no way to revert.

In practice, GetOtherReserves does not alter the hold in any meaningful way
EXCEPT for producing this invalid state in a few niche situations. In all of
those niche situations, the user is prompted to explicitly confirm, cancel, or
revert the hold. In the few niche situations where the user is able to ignore
the prompt (thereby leaving the hold in the invalid state), the hold status
shouldn't be updated anyway. We should simply remove the code from
GetOtherReserves that attempts to modify the hold.

-- 
You are receiving this mail because:
You are watching all bug changes.