You cannot use the override function (AllowFineOverride) on “Fines outstanding” on the Staff client because this stops the pay function working on the SelfCheck (SC) machines. The SIP2 devices share this system preference. Test Plan ========= 1) Set System Preference AllowFineOverride to "Allow". 2) On SIP2 device (e.g. 3M SelfCheck) try paying a fine. We see:- Borrower XXXXXXXXX had existing fines of 50p (2 x 25p). Attempted to borrow book YYYYYYYYYYYYY. Chose 'Pay Fines Later' and issue was allowed even with an outstanding (payable) fine. Tried to pay fines SelfCheck Machine asked for correct amount took money but then returned money stating it could not charge account and to enquire at desk. In the SIP2 response, character position 1 & 2 on the 64 response need to be set to Y for the SIP2 device to properly handle the block. 64YY Y 00020110614 ................. In Koha these are only set in two scenarios 1) If the user has expired and 2) if the user is debarred Needs a change in the Members logic the status in the ILS::Patron is setup on the basis of the return from GetMemberDetails it does not set the noissues flag if staff can override (AllowFineOverride option). In the staff client the noissuescharge is applied as part of the checkout transaction in 'CanBookBeIssued'.
Clarify the behaviour with AllowFineOverride set to 'dont allow' Behaviour is: Request:6300120140417 135829 AOCPL|AA23529001223654|ACsipuser|ADSIPK1|AY1AZECE8 Response:64YYYY YY 00120140417 135829000000000001000000000000AOCPL|AA23529001223654|AEMadeleine Smith|BLY|CQN|BV19.00|CC5|BDEdinburgh 1111111|PCPT|PIN|AFGreetings from Koha. -- Patron owes 19.00|AY1AZC8BA[0d][0a] Request:11YN20140417 13582920141211 235500AOCPL|AA23529001223654|AB502326000745|ACsipuserAY2AZEA61 Response:120NUN20140417 135829AOCPL|AA23529001223654|AB502326000745|AJThe hydrogen sonata /|AH|AFPatron Blocked|BLY|AY2AZDF60[0d][0a] Status response (64) returns that Patron is blocked from borrowing. An attempt to borrow (Request 11) is rejected With 'AllowFineOverride' behaviour is Request:6300120140417 140210 AOCPL|AA23529001223654|ACsipuser|ADSIPK1|AY1AZECFC Response:64 YY 00120140417 140210000000000001000000000000AOCPL|AA23529001223654|AEMadeleine Smith|BLY|CQN|BV19.00|CC5|BDEdinburgh 1111111|PCPT|PIY|AFGreetings from Koha. -- Patron owes 19.00|AY1AZC9A7[0d][0a] Request:11YN20140417 14021020141211 235500AOCPL|AA23529001223654|AB502326000745|ACsipuserAY2AZEA75 Response:121NNY20140417 140210AOCPL|AA23529001223654|AB502326000745|AJThe hydrogen sonata /|AH20140419 235900|AY2AZE3D5[0d][0a] Response now indicates borrower is not blocked from borrowing and indeed a request to issue the item succeeds. This subverts the normal behaviour as the borrower is still stopped in the online and requires staff permission to borrow. If that permission is refused the borrower can now still borrow the item if there is a self check unit available
Created attachment 27258 [details] [review] Patch fixing incorrect behaviour on issue This patch handles the blocking of loans which previously could be executed via SIP2 To test: on a system where AllowFineOverride is set to 'allow' attempt to issue an item to a borrower with fines which exceed the value to require staff override. The system should reject the issue. The issue should succeed if the borrower has no fines or fines below the value which restricts issue
Created attachment 27259 [details] [review] Second patch ensuring Patron Info is returned correctly The previous patch stopped users with 'excessive fines' (to use the SIP terminology) from issuing items to themselves. This supplementary patch includes the fact that the borrower cannot borrow to be returned in the patron information response. Typically client units request this before issuing, it was saying fines were present but not that this restricted the user's privileges. To test: See the returns from patron information requests If loan privileges are suspended the first four flags in the summary should be set to Y thus: 64YYYY YY 00120140417 163243000000000001000000000000AOCPL|AA..... (of course what the client does with this info is up to it)
Created attachment 30731 [details] [review] Bug 11633 : Block Issue if fines require staff override If a patrons fines exceed noissuescharge and we allow staff to allow issue at their discretion via an override the SIP process allowed charges to go ahead. This patch closes the loophole which allowed self issue to subvert the usual library loan policy Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Created attachment 30732 [details] [review] Bug 11633 Return Correct status if patron blocked by fines If the patron has amassed charges that block borrowing, but we allow staff override the information that the patron cannot issue should be included the patron information response This patch sets the appropriate status fields in the patron object It restores the fee_limit member to the patron object and calls a local subroutine to set it. This could be done more elegantly but that would require more major refactoring of the rather messy initializer code in ILS::Patron Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
I am not able to test SIP, so I cannot test this patch. But looking at the code, it smells good to me.
Created attachment 31099 [details] [review] [PASSED QA] Bug 11633 : Block Issue if fines require staff override If a patrons fines exceed noissuescharge and we allow staff to allow issue at their discretion via an override the SIP process allowed charges to go ahead. This patch closes the loophole which allowed self issue to subvert the usual library loan policy Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 31100 [details] [review] [PASSED QA] Bug 11633 Return Correct status if patron blocked by fines If the patron has amassed charges that block borrowing, but we allow staff override the information that the patron cannot issue should be included the patron information response This patch sets the appropriate status fields in the patron object It restores the fee_limit member to the patron object and calls a local subroutine to set it. This could be done more elegantly but that would require more major refactoring of the rather messy initializer code in ILS::Patron Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Is this bug 3.14-only?
(In reply to Tomás Cohen Arazi from comment #9) > Is this bug 3.14-only? No although it was reported at 3.14 it would be applicable to later versions
Patches pushed to master. Thanks Colin!