[Koha-devel] IndependentBranches == "softno" on SIP server

dcook at prosentient.com.au dcook at prosentient.com.au
Mon Sep 2 09:55:23 CEST 2019


Oh. I've found something interesting!

lib/Koha/Patron.pm uses "checkPrevCheckout" instead of "CheckPrevCheckout",
which is why I wasn't finding it with my case-sensitive grep. 

 

In C4::Circulation::CanBookBeIssued, I think it is very likely that
C4::Context->preference("checkPrevCheckout") is called and then the next
call is C4::Context->preference("IndependentBranches"), and somehow. the
value from "checkPrevCheckout" is being used instead of the true value of
"IndepenentBranches". Yikes!

 

I don't know how it's happening, but it's happening. 

 

I notice that Plack runs Koha::Caches->flush_L1_caches() routinely. So does
bin/migration_tools/rebuild_zebra.pl when it's run in daemon_mode. I reckon
a short-term solution would be to add that cache flushing to the SIP server
as well. 

 

However, I'm still really curious how the wrong value is being returned by
C4::Context->preference("IndependentBranches").

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

From: dcook at prosentient.com.au <dcook at prosentient.com.au> 
Sent: Monday, 2 September 2019 3:49 PM
To: 'koha-devel' <koha-devel at lists.koha-community.org>
Subject: IndependentBranches == "softno" on SIP server

 

Hi all,

 

I've been getting errors on a SIP server that indicate that
"IndependentBranches" is non-zero. However, both MySQL and Memcached have
said that "IndependentBranches" is zero. 

 

So I added some logging to the SIP server, and it's saying that the value of
"IndependentBranches" - at the time of the error - is "softno". 

 

So I looked through the Koha code and the only reference to "softno" I can
find is in regards to "CheckPrevCheckout".

 

I've checked environmental variables and every bit of code I can think of,
and I'm absolutely stumped by this one.

 

The most feasible answer to me is a caching problem. However, it happened
over the course of weeks, and it always had the same value, so that seems a
bit far-fetched too.

 

I suppose the next step is to add yet more logging, but I figured I'd reach
out to all of you to see if anyone has had a similar problem. 

 

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

 

Office: 02 9212 0899

Direct: 02 8005 0595

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190902/b1dae8bd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20190902/b1dae8bd/attachment-0001.sig>


More information about the Koha-devel mailing list