From Bug 38615: "When testing I noticed something both with and without the patch (so this is a general SIP question) If you place a hold and then try to cancel the hold with this command before checking the item into the hold shelf the SIP cancel request returns |AFError with transaction drop_hold:|" Easy to recreate with SIP emulator: 1. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode + 2. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode - 3. See the error: AFError with transaction drop_hold:
This is a combined problem of do_hold and drop_hold not handling items correctly. After step 1 of Lucas' plan, view the patron in the staff interface, they have a 'next available' hold in the biblio, not on the item In C4/SIP/ILS/Transaction/Hold.pm in do_hold: 64 my $canReserve = CanItemBeReserved( $patron, $item, $branch ); 65 if ( $canReserve->{status} eq 'OK' ) { 66 my $priority = C4::Reserves::CalculatePriority( $item->biblionumber ); 67 AddReserve( 68 { 69 priority => $priority, 70 branchcode => $branch, 71 borrowernumber => $patron->borrowernumber, 72 biblionumber => $item->biblionumber 73 } 74 ); We don't pass the itemnumber forward Then in drop_hold - we use the itemnumber to cancel, but there is no item level hold: 93 my $item = Koha::Items->find( { barcode => $self->{item}->id } ); 94 my $holds = $item->holds->search( { borrowernumber => $patron->borrowernumber } ); 95 96 return $self unless $holds->count;