git grep "checkin_no_block" C4/SIP/Sip/MsgType.pm: $status = $ils->checkin_no_block( $item_id, $trans_date, $return_date, $item_props, $cancel );
Created attachment 144856 [details] [review] Bug 32515: Ignore no-block flag in check-in message Bug 12225 changed the templates to correctly pass through the no-block flag, however, we don't have a no-block routine for checkins This patch restore previous behaviour of performing a normal checkin when no block was requested - it adds a new FIXME To test: 1 - See bug 32537 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32537 2 - Repeat test plan on that bug, noting that there is no response when no-block = Y 3 - Apply this patch 4 - Repeat the tests and confirm no-block = Y has a standard checkin response
To test, I: 1. Repeated the steps in bug 32537 (including applying that patch). 2. Applied this patch and restarted SIP (koha-sip --restart kohadev). 3. The response I got for step 4 was: root@kohadevbox:koha(bz32515)$ perl misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m checkin --item 39999000011418 -n Y Attempting socket connection to localhost:6001...connected! Use of uninitialized value $hold_mode in string eq at misc/sip_cli_emulator.pl line 124. SEND: 9300CNterm1|COterm1|CPCPL| READ: 941 Trying 'checkin' SEND: 09Y20230101 21213820230101 212138APCPL|AOCPL|AB39999000011418|ACterm1|BIN| Use of uninitialized value $data in concatenation (.) or string at misc/sip_cli_emulator.pl line 356, <GEN0> chunk 1. READ: I'm not sure if this is what is expected (as it is pretty similar to what I got for bug 32537, except the second and third series of numbers in the SEND are different), but happy to sign off if it is.
(In reply to David Nind from comment #2) > > I'm not sure if this is what is expected (as it is pretty similar to what I > got for bug 32537, except the second and third series of numbers in the SEND > are different), but happy to sign off if it is. Hi David, It looks like the SIP response is still failing on no-block, but I don't recreate Could you retest with 'restart_all' rather than just SIP to see if that works? Or try koha-sip --stop, confirm stopped, then koha-sip --start?
(In reply to Nick Clemens from comment #3) > (In reply to David Nind from comment #2) > > > > I'm not sure if this is what is expected (as it is pretty similar to what I > > got for bug 32537, except the second and third series of numbers in the SEND > > are different), but happy to sign off if it is. > > Hi David, > > It looks like the SIP response is still failing on no-block, but I don't > recreate > > Could you retest with 'restart_all' rather than just SIP to see if that > works? Or try koha-sip --stop, confirm stopped, then koha-sip --start? I'm getting a response now, so will sign off! The response is now: root@kohadevbox:koha(bz32515)$ perl misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m checkin --item 39999000011418 -n Y Attempting socket connection to localhost:6001...connected! Use of uninitialized value $hold_mode in string eq at misc/sip_cli_emulator.pl line 123. SEND: 9300CNterm1|COterm1|CPCPL| READ: 941 Trying 'checkin' SEND: 09Y20230103 23115420230103 231154APCPL|AOCPL|AB39999000011418|ACterm1|BIN| READ: 101YNN20230103 231155AOCPL|AB39999000011418|AQCPL|AJProgramming Perl /|CRREF| Maybe I forgot to flush_memcached and restart_all after stopping and starting SIP 8-;
Created attachment 144963 [details] [review] Bug 32515: Ignore no-block flag in check-in message Bug 12225 changed the templates to correctly pass through the no-block flag, however, we don't have a no-block routine for checkins This patch restore previous behaviour of performing a normal checkin when no block was requested - it adds a new FIXME To test: 1 - See bug 32537 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32537 2 - Repeat test plan on that bug, noting that there is no response when no-block = Y 3 - Apply this patch 4 - Repeat the tests and confirm no-block = Y has a standard checkin response Signed-off-by: David Nind <david@davidnind.com>
Created attachment 145370 [details] [review] Bug 32515: Ignore no-block flag in check-in message Bug 12225 changed the templates to correctly pass through the no-block flag, however, we don't have a no-block routine for checkins This patch restore previous behaviour of performing a normal checkin when no block was requested - it adds a new FIXME To test: 1 - See bug 32537 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32537 2 - Repeat test plan on that bug, noting that there is no response when no-block = Y 3 - Apply this patch 4 - Repeat the tests and confirm no-block = Y has a standard checkin response Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Blou <philippe.blouin@inlibro.com>
Tested in production with my customers, does fix the important issue in 22.05.06
Created attachment 145943 [details] [review] Bug 32515: Ignore no-block flag in check-in message Bug 12225 changed the templates to correctly pass through the no-block flag, however, we don't have a no-block routine for checkins This patch restore previous behaviour of performing a normal checkin when no block was requested - it adds a new FIXME To test: 1 - See bug 32537 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32537 2 - Repeat test plan on that bug, noting that there is no response when no-block = Y 3 - Apply this patch 4 - Repeat the tests and confirm no-block = Y has a standard checkin response Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Blou <philippe.blouin@inlibro.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Damn, annoying that we missed this in the prior bug. Still, the quick fix here works around it.. we should certainly look into implementing bug 32557 though. Passing QA as this gets us out of a hole and all works.
(In reply to Martin Renvoize from comment #8) > Bug 12225 changed the templates to correctly pass through the no-block flag, > however, we don't have a no-block routine for checkins ^^ any chance we can have a regression test?
Pushed to master for 23.05. Nice work everyone, thanks!
Nice work everyone! Pushed to stable for 22.11.x
Backported to 22.05.x for 22.05.10
depends on 12225 which I failed to backport to 21.11.x. Can't backport this one either then.