[Koha-bugs] [Bug 29348] New: GetOtherReserves fails to mark holds as waiting or in-transit

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

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

            Bug ID: 29348
           Summary: GetOtherReserves fails to mark holds as waiting or
                    in-transit
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P5 - low
         Component: Hold requests
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: nick at bywatersolutions.com
        QA Contact: testopia at bugs.koha-community.org
                CC: gmcharlt at gmail.com

ModReserveCancelAll is called when a hold is cancelled from the waiting holds
list 

This in turn calls GetOtherReserves

GetOtherReserves then calls ModReserveMinusPriority which sets the priority to
0 and then calls _FixPriority

The problem is that 'found' is still null for the holds - so it is processed by
_FixPriority and has its' priority increased by 1 - this prevents it from being
marked waiting or in transit by subsequent code

This leaves holds in an odd state where they have an itemnumber, but no status
- okay for an item level hold - but bad for bib level

To recreate:
1 - Place a bib level hold for 3 different patrons on the same bib
    The first two should be picked up at logged in branch, the third elsewhere
2 - Check-in and confirm the hold
3 - Go to Circulation->Holds awaiting pickup
4 - Cancel the hold - you get a popup asking you to check in the item to
process the hold
5 - View the biblio - see that hold has an itemnumber, but no status
6 - Check in the item, confirm the hold, cancel from waiting reserves
7 - View the biblio - third hold has the itemnumber, but no status

While we do say in the message "Check this in to process the hold" the code
indicates it will start the transfer or set the hold waiting.

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