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@lists.koha-community.org Reporter: nick@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@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.