Bug 32515 - SIP2 no block flag on checkin calls routine that does not exist
Summary: SIP2 no block flag on checkin calls routine that does not exist
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Nick Clemens (kidclamp)
QA Contact: Martin Renvoize
URL:
Keywords:
Depends on: 12225
Blocks: 32557
  Show dependency treegraph
 
Reported: 2022-12-22 14:12 UTC by Nick Clemens (kidclamp)
Modified: 2023-09-12 16:51 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
23.05.00,22.11.03,22.05.10


Attachments
Bug 32515: Ignore no-block flag in check-in message (1.88 KB, patch)
2022-12-27 20:36 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 32515: Ignore no-block flag in check-in message (1.93 KB, patch)
2023-01-03 23:17 UTC, David Nind
Details | Diff | Splinter Review
Bug 32515: Ignore no-block flag in check-in message (1.97 KB, patch)
2023-01-17 19:59 UTC, Blou
Details | Diff | Splinter Review
Bug 32515: Ignore no-block flag in check-in message (2.04 KB, patch)
2023-02-01 13:43 UTC, Martin Renvoize
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens (kidclamp) 2022-12-22 14:12:04 UTC
git grep "checkin_no_block"

C4/SIP/Sip/MsgType.pm:        $status = $ils->checkin_no_block( $item_id, $trans_date, $return_date, $item_props, $cancel );
Comment 1 Nick Clemens (kidclamp) 2022-12-27 20:36:13 UTC
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
Comment 2 David Nind 2023-01-01 21:33:31 UTC
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.
Comment 3 Nick Clemens (kidclamp) 2023-01-03 12:11:19 UTC
(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?
Comment 4 David Nind 2023-01-03 23:16:10 UTC
(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-;
Comment 5 David Nind 2023-01-03 23:17:58 UTC
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>
Comment 6 Blou 2023-01-17 19:59:49 UTC
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>
Comment 7 Blou 2023-01-17 20:01:04 UTC
Tested in production with my customers, does fix the important issue in 22.05.06
Comment 8 Martin Renvoize 2023-02-01 13:43:57 UTC
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>
Comment 9 Martin Renvoize 2023-02-01 13:46:22 UTC
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.
Comment 10 Tomás Cohen Arazi 2023-02-02 12:33:53 UTC Comment hidden (obsolete)
Comment 11 Tomás Cohen Arazi 2023-02-06 21:36:06 UTC
Pushed to master for 23.05.

Nice work everyone, thanks!
Comment 12 Matt Blenkinsop 2023-02-07 15:18:25 UTC
Nice work everyone!

Pushed to stable for 22.11.x
Comment 13 Lucas Gass 2023-02-14 22:26:38 UTC
Backported to 22.05.x for 22.05.10
Comment 14 Arthur Suzuki 2023-02-17 10:14:38 UTC
depends on 12225 which I failed to backport to 21.11.x.
Can't backport this one either then.