Open GoogleCodeExporter opened 8 years ago
Turn off error reporting and see if it works.
Original comment by kirkenda...@gmail.com
on 11 Dec 2012 at 12:26
Turned off error reporting. Entering a library card now gets past the "Checking
your account" message. Where the patron's name should be, however, there is
just an exclamation point (attachment 1). The patron's current items out isn't
displayed, etc. Basically doesn't seem to actually be pulling up a patron
account. Scanning an item gives a pop-up OK box (attachment 2), but doesn't add
the item to the list to check out.
When trying to generate a response for a renewed item with responses.php, it
outputs at the top of the screen:
Array ( [fixed] => Array ( [Ok] => [RenewalOk] => [Magnetic] => [Desensitize]
=> [TransactionDate] => ) [variable] => Array ( [Raw] => Array ( [0] => ) [AZ]
=> Array ( [0] => ) ) )
And nothing else. Clicking "Click here to take a look" likewise gives nothing
(not even an array above).
If I play around with the sip2.php script around line 799 that was throwing the
original errors I can get some interesting results, but I can't make much of
them. The original code there is
$test = preg_split('/(.{4})$/',trim($message),2,PREG_SPLIT_DELIM_CAPTURE);
if ($this->_crc($test[0]) == $test[1]) {
return true;
} else {
return false;
}
If I comment out everything in the if statement except for 'return true;',
responses.php will give me a response message, and the array at the top of the
screen will display accurate information about the item (title name, etc.)
If I do the same thing except for 'return false;', then the exclamation mark
business returns and responses.php generates nothing, as above.
Thanks so much for your time and consideration! I'm starting to feel like maybe
there's something we're screwing up in the communication between our SIP2
server, so I'll be in contact with our vendor about that today. Figured I'd try
posting here to see if you have any troubleshooting suggestions or any idea
what might be going on first. It's definitely appreciated! :)
Original comment by kkaffenb...@greensburglibrary.org
on 11 Dec 2012 at 6:02
Attachments:
I can't reproduce the error but I've run into similar hiccups with the SIP2
class. It looks like the line you're talking about (799) is just some sort of
extra validity check on the data being returned from your SIP server. You can
probably safely leave it to simply return true without affecting anything. Let
me know if you have any other problems.
Original comment by ericmelton1@gmail.com
on 11 Dec 2012 at 6:34
Oops, I forgot to mention that commenting out the lines doesn't enable the
software to work successfully.
When returns true is set, the "There's a problem with your account. Please see
a circulation clerk" message appears when trying to scan a library card.
When returns false is set, we can scan a barcode successfully, but patron
information won't pull up (the ! and blank account info in the attachments
above)
Thanks again for your responses!
Original comment by kkaffenb...@greensburglibrary.org
on 11 Dec 2012 at 7:22
OK. You're probably getting that error because that function (on line ~798) is
trying to check a value that is empty or doesn't exist because the self-check
is not sending it or is not sending it correctly. You've probably checked the
obvious like 1)if your sip2 connection requires a password it is set 2)the port
to the sip server is open to the selfcheck and 3) if your ils has a
configuration setup for sip make sure it's configured correctly. I can't think
of what else could be going on.
Original comment by ericmelton1@gmail.com
on 11 Dec 2012 at 7:33
It's an odd problem, as when I login to our SIP2 server (which is kept offsite,
though that shouldn't matter) through a terminal and manually enter expected
strings (eg. 9300CNusername|COpassword|CP), I get the expected results.
I know it's a dumb question, but is there a way I would be able to print the
raw string(s) being sent and received? I think that if I could see that, I
would have a pretty good idea of what to tinker with.
Thanks again!
Original comment by kkaffenb...@greensburglibrary.org
on 13 Dec 2012 at 8:35
In responses.php any of the variables with msg or message are raw so you could
echo or print_r, for example, $mysip->msgLogin($sip_login,$sip_password) or
$mysip->get_message($cko) that should give you what is being sent back and
forth before any parsing or changes are made to the data.
Original comment by ericmelton1@gmail.com
on 14 Dec 2012 at 8:21
Working with Kieth and I found this section of code:
if (strpos($patron_info['fixed']['PatronStatus'],'Y') !== false OR
(!empty($patron_info['variable']['BL'][0]) &&
$patron_info['variable']['BL'][0]!='Y')){ //blocked or non-existent account?
session_regenerate_id();
session_destroy();
echo json_encode('blocked account');
exit;
}
It seems that changing the !== to === fixes the problem. Does anyone see a
problem with this? It was returning that the account was blocked instead of
allowing it to go through.
BTW: We are with Evergreen ILS, not sure if that makes a difference.
Thanks!
Conlin
For explanation purposes the fixed code becomes:
if (strpos($patron_info['fixed']['PatronStatus'],'Y') === false OR
(!empty($patron_info['variable']['BL'][0]) &&
$patron_info['variable']['BL'][0]!='Y')){ //blocked or non-existent account?
session_regenerate_id();
session_destroy();
echo json_encode('blocked account');
exit;
}
Original comment by Conlindu...@gmail.com
on 17 Dec 2012 at 9:20
Confirmed that changing the above code in account_check.php fixes the problem
we were having when we also forced the check_crc function in sip2.php to return
true.
Thanks again to you both for all the help, support, and hard work!
Original comment by kkaffenb...@greensburglibrary.org
on 17 Dec 2012 at 9:48
Strange. The response from your ILS must be slightly off the SIP2 standards.
Anyway, I'm glad you got it working. Let me know if you have any other
questions.
Original comment by kirkenda...@gmail.com
on 18 Dec 2012 at 12:03
Original issue reported on code.google.com by
kkaffenb...@greensburglibrary.org
on 10 Dec 2012 at 11:40