Renew doesn't renew

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Check something out.
2.Check out something that is already checked out.  SC will prompt that it is 
already checked out.  Do you want to renew?
3.Click Yes.  

What is the expected output? What do you see instead?
The item should be renewed
Instead another popup comes up and says “Item unavailable due to outstanding 
holds”.  No transaction takes place.  There is no hold on the item.

What version of the product are you using? On what operating system?
1.2 on Windows 7 with Firefox.

Please provide any additional information below.

Original issue reported on code.google.com by CDASupp...@gmail.com on 28 Apr 2012 at 7:45

[GoogleCodeExporter]

Forgot to mention, we are working with Koha 3.6.  The sip connection works 
great.

Original comment by CDASupp...@gmail.com on 28 Apr 2012 at 7:45

[GoogleCodeExporter]

Have you looked at your selfcheck/sip rules for your ILS? There is probably a 
rule that sets whether renewals are allowed via selfcheck. Make sure that is 
set to allow renewals.

Original comment by ericmelton1@gmail.com on 28 Apr 2012 at 10:08

[GoogleCodeExporter]

Hi Eric,
Yes, the rules are set to allow renewals.  As stated, the wrong message comes 
up, stating there is a hold on the item, when there is not.  Furthermore, the 
item renews only if it is the first item (it is not showing the list of items 
yet).  However, it doesn't show it as a renewal once the list comes up.  It 
just shows it as a checkout.  Yet, when I look in Koha, it shows it is renewed.

Christopher

Original comment by CDASupp...@gmail.com on 4 Jun 2012 at 4:42

[GoogleCodeExporter]

The problem doesn't seem to be in it recognizing that the items is renewable.  
As stated up above, it gives the message that the item is already checked out.  
It just does something completely different when you tell it to do so.

Christopher

Original comment by CDASupp...@gmail.com on 4 Jun 2012 at 5:04

[GoogleCodeExporter]

I'm a little confused. The self check does not set rules as to what can or 
can't be renewed -it only responds to the messages that your ILS sends back 
when you attempt a SIP transaction. In addition, the messages it shows are 
those sent by your ILS (not ones that are in the self-check) so the holds 
message is being sent by your ILS. Have you changed $already_ckdout_to_you in 
config.php to match your ILS's response to an attempted renewal (this can be 
found by bringing up responses.php in your browser).

Original comment by ericmelton1@gmail.com on 4 Jun 2012 at 6:20

[GoogleCodeExporter]

Disregard my last sentence above. 

Original comment by ericmelton1@gmail.com on 4 Jun 2012 at 6:23

[GoogleCodeExporter]

I am confused as well.  It seems that when an item that is checked out already 
is scanned as a first item, it doesn't ask you if you want to renew it, but it 
looks like a new checkout, yet it is really being renewed.  So, it CAN be 
renewed.  It just doesn't want to if it is after the first item.  There just 
seems to be something that is tripping it up.  I'm not sure what it is though.  
We are using the same sip connection for PC Reservation, and it isn't having 
any trouble with it, although it isn't circulating any items.  It is simply 
checking authentication and blocks.

Christopher

Original comment by CDASupp...@gmail.com on 4 Jun 2012 at 6:44

[GoogleCodeExporter]

Have you tried renewing something that has not been checked out on the day 
you're renewing it? It seems that the hold response is a default response 
anytime an item is not available for renewal(see below code from Koha). I'm 
wondering if it's not allowing the renewal because that would result in the 
same due date it already has (shot in the dark).

 if (!defined($item)) {
$trans->screen_msg("Item not checked out to " . $patron->name); # not checked 
out to $patron_id
        $trans->ok(0);
    } elsif (!$item->available($patron_id)) {
$trans->screen_msg("Item unavailable due to outstanding holds");
        $trans->ok(0);
    } else {

Original comment by ericmelton1@gmail.com on 4 Jun 2012 at 7:06

[GoogleCodeExporter]

Try deleting the text in $already_ckdout_to_you in config.php. This might solve 
the problem but you may lose the renewal prompt -things would just be checked 
out/renewed like the first item is doing now.

Original comment by ericmelton1@gmail.com on 4 Jun 2012 at 7:59

[GoogleCodeExporter]

I tried your suggestion in Comment #8 first.  Without touching the 
$already_ckdout_to_you in config.php (I left the text there), it renewed, but 
didn't even show as a renewal.  It looks like a checkout in the self check.  It 
does not prompt about a renewal.

I've been able to do further testing based on your responses:

If I have an item checked out, and I try to renew it as the first item scanned, 
it renews, but looks like a check out in the self check, regardless of when the 
item is due.  It does not prompt about a renewal.

If I have an item checked out, and the renewal due date is the same as the 
original due date, and is not the first item scanned, the self check treats it 
like a renewal, but when you confirm the renewal, it fails (I get the message 
about a hold).

If I have an item checked out, and the renewal due date is different than the 
original due date, and is not the first item scanned, the item renews, but 
looks like a check out to the self check.  It does not prompt about a renewal.

If I remove the text as suggested in comment 9, I no longer get the error.  
This at least makes the self check act more consistent without the error.  Not 
sure why the renewal method goes sideways.

I hope this helps.  I'm trying to trace the logic of the code, but I am not 
very strong in php, so I'm having difficulty tracking the logic.

Christopher

Original comment by CDASupp...@gmail.com on 4 Jun 2012 at 8:34

[GoogleCodeExporter]

By doing what I mentioned in comment 9 you're ending up with functionality like 
we currently have. Polaris does not send a response when an item is already 
checked out to an account -it just renews it. It's been fine for us.

Original comment by ericmelton1@gmail.com on 4 Jun 2012 at 8:37

[GoogleCodeExporter]

Original comment by ericmelton1@gmail.com on 8 Jun 2012 at 6:39

• Changed state: Done