Bug 23780 - Batch check out fails to inform or trap
Summary: Batch check out fails to inform or trap
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-08 16:45 UTC by Christopher Brannon
Modified: 2022-04-12 11:56 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 23780: Add DEBT info to batch checkouts info (1.38 KB, patch)
2019-10-15 14:16 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2019-10-08 16:45:58 UTC
I have managed to catch failures in Batch check out on the following scenario:

Patron has fines over the allowed limit.  Item type only allows 5 check outs.

When checking out 6 of this item type, Batch check out failed to:
* Show any information that the patron had reached fine limit
* Show that the patron was checking out too many of this item type

If I checked out these 6 items without the fine, it gives the warning about too many items and asks me to confirm.

If I check out 5 of these items with the fine, it does not explain why I need to confirm.

It seems that Batch check out:
* Is not displaying a reason for confirmation with the fine block.
* Is not displaying a reason for confirmation when there are multiple blocks.
Comment 1 Jonathan Druart 2019-10-15 14:16:40 UTC
Created attachment 94216 [details] [review]
Bug 23780: Add DEBT info to batch checkouts info

DEBT can be impossible or needs confirmation.

Test plan:
Create an invoice of 50 (and make sure 50 is above the limit)
Check an item out using the batch checkouts feature
=> You should see the warning in the "Information" column
Comment 2 Christopher Brannon 2019-10-15 16:08:38 UTC
(In reply to Jonathan Druart from comment #1)
> Created attachment 94216 [details] [review] [review]
> Bug 23780: Add DEBT info to batch checkouts info
> 
> DEBT can be impossible or needs confirmation.
> 
> Test plan:
> Create an invoice of 50 (and make sure 50 is above the limit)
> Check an item out using the batch checkouts feature
> => You should see the warning in the "Information" column

Technically, it works for the fines, but if I have multiple reasons, it only shows one reason and lets you blow past the other unknowingly.

For this to work as expected, it needs to show ALL reasons.

To test:
* Set checkout limit to 5 items.
* Set MaxFine to 3
* Set borrower with a manual invoice of $5.
* Batch checkout 6 items.  You will see information on every item that the patron has a debt of 5.00, but on the 6th item, you should ALSO see "Too many checked out".

The problem is other items are not already checked out to trap this.  SO, what needs to happen is either 
A) the batch checkout needs to "Look ahead" at all issues and evaluate all potential blocks, or
B) the batch checkout needs to run through the same process again on all the checked items and catch the next block.

Process A would be preferable so you don't have to override over and over again through each scenario.

I want to sign off, because this is a step in the right direction, but it does not address the multiple blocks addressed in the description of the problem.
Comment 3 Jonathan Druart 2019-10-16 08:09:21 UTC
Ok, got it now.

Actually it's not the "multiple blocks" that is the problem, but the "too many" that cannot be guessed.

For instance if you already have 5 checkouts and over the fine limit, you will get the 2 warnings.

> * Batch checkout 6 items.  You will see information on every item that the patron has a debt of 5.00, but on the 6th item, you should ALSO see "Too many checked out".

Until the limit is reached we cannot guess it in advance, because we cannot simulate a checkout. We could add an additional screen for this specific case, but it's much more complex that the first patch I submitted.
Comment 4 Christopher Brannon 2019-10-16 14:37:58 UTC
Well, either way, if all we are being told about is the fines and not the number of checkouts, overriding the fines completely bypasses other blocks, and this is a HUGE problem.  Either Koha is going to have to look ahead at all potential blocks before checkout, or it is going to have to run through the checkout process multiple times.

Theoretically, if all 6 items are showing the fines block, and you have all 6 items checked for override, shouldn't it check each item in again and then run into the next block on the 6th item?

It seems what is happening is an overall override, rather than a specific block override.  The override for the fines is also overriding or bypassing the block for the item limit.

I'm wondering if Koha needs to have a smarter override system, in that the override targets a specific block, and is not just a general, ignore everything override.
Comment 5 Jonathan Druart 2019-10-23 14:07:12 UTC
I'd suggest to separate the two issues as one is fixed and the other one is complex and will certainly not be fixed soon.
Comment 6 David Nind 2021-03-01 16:38:55 UTC
I'm not sure how to trigger this when testing.

Before applying the patch, and if I add an invoice for $50 (which is over the limit), I get this message on batch check out screen:

Cannot check out!
Charges: Patron has outstanding charges of 50.00. Checkouts are BLOCKED because fine balance is OVER THE LIMIT. [Make payment][Pay all fines]

Patch still applies.
Comment 7 Jonathan Druart 2021-03-02 09:27:42 UTC
(In reply to David Nind from comment #6)
> I'm not sure how to trigger this when testing.
> 
> Before applying the patch, and if I add an invoice for $50 (which is over
> the limit), I get this message on batch check out screen:
> 
> Cannot check out!
> Charges: Patron has outstanding charges of 50.00. Checkouts are BLOCKED
> because fine balance is OVER THE LIMIT. [Make payment][Pay all fines]
> 
> Patch still applies.

You are right, it has been fixed by bug 19382.
Comment 8 Katrin Fischer 2021-03-04 09:56:00 UTC
Hm, so should we change the bug title to indicate a part of this has already been fixed?