[Koha-bugs] [Bug 24966] New: Fix calls to maybe_add where method call does not return a value

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

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

            Bug ID: 24966
           Summary: Fix calls to maybe_add where method call does not
                    return a value
 Change sponsored?: ---
           Product: Koha
           Version: master
          Hardware: All
                OS: All
            Status: NEW
          Severity: critical
          Priority: P5 - low
         Component: SIP2
          Assignee: koha-bugs at lists.koha-community.org
          Reporter: kyle at bywatersolutions.com
        QA Contact: testopia at bugs.koha-community.org
                CC: colin.campbell at ptfs-europe.com

For reasons unknown to me, a call like:
--
$resp .= maybe_add( FID_CALL_NUMBER, $item->call_number, $server );
--
will not work as expected if the item has no callnumber.

One would expect the parameters to the subroutine to be: 'CY', under, and a
SIPServer object.

What is actually received is: 'CY', and a SIPServer object.

We ingest the parameters like so:
--
sub maybe_add {
    my ($fid, $value, $server) = @_;
--
So, what happens is $value is populated with the server object!

This can cause bad output like this:
--
OUTPUT MSG: '101YNN20200324    063701AOBPL|AB32503201584185|AQBPL|AJCat
/|CK001|CRn|CSJ 636.8
CLU|CYC4::SIP::SIPServer=HASH(0x1ea0e58)|DAC4::SIP::SIPServer=HASH(0x1ea0e58)|'---

I do not know why this is happening, but there are a couple solutions:
1) Move the $server parameter to be the first parameter of the subroutine call
2) Check the value of $value and swap $value and $server if it is the server
object.

I will write a patch implementing the latter solution, as it is a two line
change, versus a many line change for the former.

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