https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com --- Comment #2 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Did you managed to confirm this one Nick? I'm wondering if it's now 'gone away' or still needs investigating. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #4 from Michael Hafen <michael.hafen@washk12.org> --- Created attachment 127816 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=127816&action=edit Proposed fix -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #5 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- This looks good.. My one query is around the `|| !C4::Context->preference('CalculateFinesOnReturn')` introduction.. I'm not sure if that's the behaviour we want/expect.. should we still increment a fine after return here? I realise, it's to do with the job being long running and so the patron has 'got away with it' as it were.. but we could be introducing questions if the patron returns their item, pays their fine and then finds they have a bit more to pay after the fact because the calculations were still running? Otherwise, I think this is a great little improvement. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #7 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 127852 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=127852&action=edit Bug 18855: (follow-up) Restore CalculateFinesOnReturn behaviour This patch removes the check for a disabled 'CalculateFinesOnReturn' to restore the behaviour prior to this patch series. If a patron has returned the item during the fines cron run, they may well have been charged a reduced fine at check-in time. However, I feel that the fine should not then increment/decrement behind the scenes after the check-in. This is to reduce confusion for end users and librarians alike. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #8 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Signing off.. leaving to QA/RM to decide whether to keep my follow-up or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #9 from Michael Hafen <michael.hafen@washk12.org> --- I am totally in agreement with you on this. (In reply to Martin Renvoize from comment #7)

Created attachment 127852 [details] [review] Bug 18855: (follow-up) Restore CalculateFinesOnReturn behaviour

This patch removes the check for a disabled 'CalculateFinesOnReturn' to restore the behaviour prior to this patch series.

If a patron has returned the item during the fines cron run, they may well have been charged a reduced fine at check-in time. However, I feel that the fine should not then increment/decrement behind the scenes after the check-in. This is to reduce confusion for end users and librarians alike.

-- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila@collect | |o.ca -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Michael Hafen <michael.hafen@washk12.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #127851|0 |1 is obsolete| | Attachment #127852|0 |1 is obsolete| | --- Comment #12 from Michael Hafen <michael.hafen@washk12.org> --- Created attachment 128187 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128187&action=edit Proposed fix in cronjobs/fines.pl This changes cronjobs/fines.pl instead of C4/Overdues.pm Test plan: 1. find an overdue fine near the end of the list of overdue fines that cronjobs/fines.pl will be considering. 2. start cronjobs/fines.pl. 3. immediately check in or renew the overdue book. 4. once fines.pl is finished observe that a duplicate overdue fine has been created on the patrons account. 5. apply patch. 6. repeat 1 - 4 and observe that the duplicate fine was not created. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Patrick Robitaille <patrick.robitaille@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |patrick.robitaille@collecto | |.ca -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Michael Hafen <michael.hafen@washk12.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #14 from Michael Hafen <michael.hafen@washk12.org> --- (In reply to Andreas Jonsson from comment #13)

Using a table lock seems like a crude solution.

Why not use a transaction?

I agree that the table lock is pretty ugly. Honestly, I haven't tested that it solves the problem either. Think of it, it probably creates a problem where the accountlines table is locked during circulation. (I just found out that foreign key tables also get locked, which compounds this problem.) But a transaction would not prevent multiple threads from changing the same row, which is what I was trying to catch there. I'd be fine with going back to Martin's patches. (But a test would still have to be written. ;) ) Besides, I'm not even using the table locking patch in production here. I've moved on from this, so I'll have to dig in a bit to remember what all is going on, to figure out how much of a problem the 'renewed is still overdue so new fine' case is. This keys on the issue_id, but maybe that can be changed to key on the accountlines_id instead; that would be a better solution to this problem I think. I'll dig in a bit and see if I can get this to key on the accountlines_id instead. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #15 from Michael Hafen <michael.hafen@washk12.org> --- I think I figured out why the code here was the way it was. It has to do with the possibility of a book being renewed and then becoming overdue again. The way the code was there would be a second overdue fine added to the account lines for this second instance of the issue becoming overdue. With the patches to dropping the status check the second overdue fine would never get entered since the previous overdue fine would be found instead. And the table locking patch doesn't lock the table soon enough to fix the duplication problem. (Which is besides the fact that locking in a long running process would totally kill the circulation desk.) Which brings me back to using accountlines_id to find the overdue fine instead of issue_id. We need to either make sure the fines cron job doesn't run during circulation hours, or find and use the accountlines_id when pulling the list of overdues. Those are the best solutions I can think of, either run the script when things aren't going to change, or make sure the script can find the right account line in case things change so we don't have a duplicate. So, I need to either patch cronjobs/fines.pl and C4/Overdues.pm to use accountlines_id, or patch the cron files to specify when the fines cron job runs (move some jobs from cron.daily to cron.d). I prefer patching fines.pl and C4/Overdues.pm, since I can't be sure how long the cron jobs would run, and some should finish before others start. Options and alternate solutions welcome. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Michael Hafen <michael.hafen@washk12.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #18 from Michael Hafen <michael.hafen@washk12.org> --- Here's the test plan from the patch file: Test plan: 1. find an overdue fine near the end of the list of overdue fines that cronjobs/fines.pl will be considering. 2. start cronjobs/fines.pl. 3. immediately check in the overdue book. 4. once fines.pl is finished observe that a duplicate overdue fine has been created on the patrons account. 5. apply patch. 6. repeat 1 - 4 and observe that the duplicate fine was not created. Re: your comment (I replied to the email, but don't see it here): Yes, that would be normal operation. The fine for the issue is identified by being unreturned. If a book is renewed it's fine is returned, and if it becomes overdue again the UpdateFine call will create the new one. The bug is if an overdue book is returned or renewed while the script is running, but before the script has processed that issue, then it's fine will be returned, but the script still called UpdateFine, so another fine is created since it couldn't find the one that was just changed to returned. I've changed the script to check the issue before calling UpdateFine, and skip the call this time if the issue (due date) changed to avoid the duplicate fine. There is still a very narrow window where UpdateFine gets called and at the same time the fine is changed to returned, but I think that chance is small enough to overlook. The alternate would be to lock the tables before calling UpdateFine, but that would slow down the circulation desk while the fines script runs, which would probably bring complaints. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #20 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Your patch felt a bit dirty at first but I don't have anything else to suggest actually. I've added a follow-up patch to tidy a bit the code around your changes. I am wondering about the "$counted" variable. When do we need to increment it? In my understanding it's correct with my patch (and was not before) but I am not 100% sure. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Amit Gupta <amitddng135@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amit.gupta@informaticsgloba | |l.com, | |amitddng135@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #23 from Michael Hafen <michael.hafen@washk12.org> --- (In reply to Caroline Cyr La Rose from comment #22)

Hi all, I'm curious to know the usefulness of having the fines.pl cron run during library operation hours... If anyone can enlighten me on this, I would be very grateful.

The fines.pl is part of the daily cron job, which starts around 2:30 on my system. (as per /etc/crontab) By the time the daily cron job gets done with fines it's after 6, which is when some of my libraries open (I'm running Koha for a School District). It's probably not intended to be run during operation hours, it just happens to for me. I'll rebase the patch for current master and upload it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Michael Hafen <michael.hafen@washk12.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #25 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Created attachment 144084 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=144084&action=edit Bug 18855: Don't create duplicate overdue fines if an issue is returned This includes Jonathan's followup If cronjobs/fines.pl is running during circulation hours, then an issue may be considered for having it's overdue fine updated after the issue has been returned and it's fine status flipped from 'UNRETURNED' to 'RETURNED'. In this case UpdateFine will create a duplicate fine because it can't find the specific accountline for the (formerly) overdue issue. This changes cronjobs/fines.pl to double check the issue before updating the fine. If the issue has changed between starting the script and updating the fine, then the script will skip it. There is a small amount of time between the check and calling UpdateFine where the issue can be changed and this problem can reoccure. The chance of that happening is so small that it's probably fine to leave as is. It is also possible that the fine won't be updated because the issue was returned. In this case the fine payed by the patron will be lower, but that is better then the patron finding later that there is more to a fine they thought they had paid all of. Test plan (by Caroline): 0. Preliminary settings 0.1. finesMode system preference must be set to Calculate and charge 0.2. There must be a circulation rule that will charge fines (beware of bug 32271) 0.3. In Tools > Calendar, today must not be a holiday 1. Make a lot of overdue checkouts - I used the batch checkout feature, but if your system already has a lot of overdue checkouts, you can skip to step 2 1.1. Enable batch checkouts 1.1.1. Go to Administration > Global system preferences 1.1.2. Search for BatchCheckouts 1.1.3. Set BatchCheckouts to Allow 1.1.4. Select all categories in BatchCheckoutsValidCategories 1.1.5. Click "Save all Circulation preferences" 1.2. Get a list of barcodes 1.2.1. Go to Reports 1.2.2. Click "Create from SQL" 1.2.3. Give the report a name 1.2.4. For the SQL query, enter SELECT barcode FROM items WHERE onloan IS NULL LIMIT 60; 1.2.5. Click "Save report" 1.2.6. Click "Run report" 1.2.7. Click "Download" > "Tab separated text" 1.3. Go to a patron's file 1.3.1. Go to Patrons 1.3.2. Click on "Search" 1.3.3. Click on a patron's name 1.4. Do a batch checkout with a due date in the past 1.4.1. Click on the "Batch check out" tab on the left 1.4.2. In "Use a file", click "Choose file" 1.4.3. Choose the file downloaded from the report 1.4.4. In "Hard due date", choose a date in the past 1.4.5. Click "Check out" 1.4.6. Click "Checkout or renew" 2. Find the last issue in the database 2.1. In the database (or in reports), type the following query SELECT issues.*, items.itype as itemtype, items.homebranch, items.barcode, items.itemlost, items.replacementprice, items.biblionumber FROM issues LEFT JOIN items USING (itemnumber) WHERE date_due < NOW() \G; 2.2. Copy the barcode from the last entry 3. Set up so that you can run fines.pl and check in the item at the same time (or very close to the same time) 3.1. In Koha, click the "Check in" option in the search bar at the top of the page 3.2. Paste the barcode in the search bar BUT DO NOT PRESS ENTER OR THE ARROW RIGHT AWAY 3.3. In a terminal, enter the fines.pl command ./misc/cronjobs/fines.pl 3.4. Execute the command and immediately click on the arrow in the staff interface to check in the item 4. Check the patron's fines 4.1. Click on the patron's name in the check in screen 4.2. Go to the Accounting tab on the left 4.3. In the search box just above the table, paste in the returned item's barcode --> Without the patch, there are two fines, one Fine (Accruing) and one Fine (Returned) for the same item at the same time --> With the patch, there is only one fine, Fine (Returned) Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #27 from Michael Hafen <michael.hafen@washk12.org> --- (In reply to Caroline Cyr La Rose from comment #26)

Wow, thanks for the quick rebase Michael!

I tested and I only have one fine, Fine (Returned), now.

You're welcome. Thanks for the sign off. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #29 from Michael Hafen <michael.hafen@washk12.org> --- The problem comes because the script can't find the right account line, because the fine changed status to returned after the script started but before the script got to that issue. I don't think we can avoid the extra database queries because the database is change elsewhere while the fines script is running. I could add a command line option, but that creates the situation where a library may have this problem, and in looking for a solution they find the command line option. Wouldn't they wonder why the option didn't default to on to avoid the problem? Anyway, I'll go ahead and add the command line option. I want to get this moving. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Michael Hafen <michael.hafen@washk12.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Sam Lau <samalau@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #145496|0 |1 is obsolete| | --- Comment #31 from Sam Lau <samalau@gmail.com> --- Created attachment 151647 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=151647&action=edit Bug 18855: Don't create duplicate overdue fines if an issue is returned This includes Jonathan's followup If cronjobs/fines.pl is running during circulation hours, then an issue may be considered for having it's overdue fine updated after the issue has been returned and it's fine status flipped from 'UNRETURNED' to 'RETURNED'. In this case UpdateFine will create a duplicate fine because it can't find the specific accountline for the (formerly) overdue issue. This changes cronjobs/fines.pl to double check the issue before updating the fine. If the issue has changed between starting the script and updating the fine, then the script will skip it. There is a small amount of time between the check and calling UpdateFine where the issue can be changed and this problem can reoccure. The chance of that happening is so small that it's probably fine to leave as is. It is also possible that the fine won't be updated because the issue was returned. In this case the fine payed by the patron will be lower, but that is better then the patron finding later that there is more to a fine they thought they had paid all of. Test plan (by Caroline): 0. Preliminary settings 0.1. finesMode system preference must be set to Calculate and charge 0.2. There must be a circulation rule that will charge fines (beware of bug 32271) 0.3. In Tools > Calendar, today must not be a holiday 1. Make a lot of overdue checkouts - I used the batch checkout feature, but if your system already has a lot of overdue checkouts, you can skip to step 2 1.1. Enable batch checkouts 1.1.1. Go to Administration > Global system preferences 1.1.2. Search for BatchCheckouts 1.1.3. Set BatchCheckouts to Allow 1.1.4. Select all categories in BatchCheckoutsValidCategories 1.1.5. Click "Save all Circulation preferences" 1.2. Get a list of barcodes 1.2.1. Go to Reports 1.2.2. Click "Create from SQL" 1.2.3. Give the report a name 1.2.4. For the SQL query, enter SELECT barcode FROM items WHERE onloan IS NULL LIMIT 60; 1.2.5. Click "Save report" 1.2.6. Click "Run report" 1.2.7. Click "Download" > "Tab separated text" 1.3. Go to a patron's file 1.3.1. Go to Patrons 1.3.2. Click on "Search" 1.3.3. Click on a patron's name 1.4. Do a batch checkout with a due date in the past 1.4.1. Click on the "Batch check out" tab on the left 1.4.2. In "Use a file", click "Choose file" 1.4.3. Choose the file downloaded from the report 1.4.4. In "Hard due date", choose a date in the past 1.4.5. Click "Check out" 1.4.6. Click "Checkout or renew" 2. Find the last issue in the database 2.1. In the database (or in reports), type the following query SELECT issues.*, items.itype as itemtype, items.homebranch, items.barcode, items.itemlost, items.replacementprice, items.biblionumber FROM issues LEFT JOIN items USING (itemnumber) WHERE date_due < NOW() \G; 2.2. Copy the barcode from the last entry 3. Set up so that you can run fines.pl and check in the item at the same time (or very close to the same time) 3.1. In Koha, click the "Check in" option in the search bar at the top of the page 3.2. Paste the barcode in the search bar BUT DO NOT PRESS ENTER OR THE ARROW RIGHT AWAY 3.3. In a terminal, enter the fines.pl command ./misc/cronjobs/fines.pl 3.4. Execute the command and immediately click on the arrow in the staff interface to check in the item 4. Check the patron's fines 4.1. Click on the patron's name in the check in screen 4.2. Go to the Accounting tab on the left 4.3. In the search box just above the table, paste in the returned item's barcode --> Without the patch, there are two fines, one Fine (Accruing) and one Fine (Returned) for the same item at the same time --> With the patch, there is only one fine, Fine (Returned) Signed-off-by: Sam Lau <samalau@gmail.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|BLOCKED |Failed QA --- Comment #33 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Some observations: It is very good to add the parameter. That will make people more comfortable. But you check twice and the first time without. Could we remove the first check? And just depend on the last one (that has the parameter test)? The time between those two checks will be limited. After we did ++$counted; you still do a next in the second check, should we decrement counted again? Minor thing, bit picky.. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Michael Hafen <michael.hafen@washk12.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Michael Hafen <michael.hafen@washk12.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #152907|0 |1 is obsolete| | --- Comment #36 from Michael Hafen <michael.hafen@washk12.org> --- Created attachment 152987 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=152987&action=edit Bug 18855: Don't create duplicate overdue fines if an issue is returned [ rebased 2023-07-03 to include suggestion from Marcel de Rooy and previous QA comments skip a database call by not instantiating the issue object twice ] This includes Jonathan's followup If cronjobs/fines.pl is running during circulation hours, then an issue may be considered for having it's overdue fine updated after the issue has been returned and it's fine status flipped from 'UNRETURNED' to 'RETURNED'. In this case UpdateFine will create a duplicate fine because it can't find the specific accountline for the (formerly) overdue issue. This changes cronjobs/fines.pl to double check the issue before updating the fine. If the issue has changed between starting the script and updating the fine, then the script will skip it. There is a small amount of time between the check and calling UpdateFine where the issue can be changed and this problem can reoccure. The chance of that happening is so small that it's probably fine to leave as is. It is also possible that the fine won't be updated because the issue was returned. In this case the fine payed by the patron will be lower, but that is better then the patron finding later that there is more to a fine they thought they had paid all of. Test plan (by Caroline): 0. Preliminary settings 0.1. finesMode system preference must be set to Calculate and charge 0.2. There must be a circulation rule that will charge fines (beware of bug 32271) 0.3. In Tools > Calendar, today must not be a holiday 1. Make a lot of overdue checkouts - I used the batch checkout feature, but if your system already has a lot of overdue checkouts, you can skip to step 2 1.1. Enable batch checkouts 1.1.1. Go to Administration > Global system preferences 1.1.2. Search for BatchCheckouts 1.1.3. Set BatchCheckouts to Allow 1.1.4. Select all categories in BatchCheckoutsValidCategories 1.1.5. Click "Save all Circulation preferences" 1.2. Get a list of barcodes 1.2.1. Go to Reports 1.2.2. Click "Create from SQL" 1.2.3. Give the report a name 1.2.4. For the SQL query, enter SELECT barcode FROM items WHERE onloan IS NULL LIMIT 60; 1.2.5. Click "Save report" 1.2.6. Click "Run report" 1.2.7. Click "Download" > "Tab separated text" 1.3. Go to a patron's file 1.3.1. Go to Patrons 1.3.2. Click on "Search" 1.3.3. Click on a patron's name 1.4. Do a batch checkout with a due date in the past 1.4.1. Click on the "Batch check out" tab on the left 1.4.2. In "Use a file", click "Choose file" 1.4.3. Choose the file downloaded from the report 1.4.4. In "Hard due date", choose a date in the past 1.4.5. Click "Check out" 1.4.6. Click "Checkout or renew" 2. Find the last issue in the database 2.1. In the database (or in reports), type the following query SELECT issues.*, items.itype as itemtype, items.homebranch, items.barcode, items.itemlost, items.replacementprice, items.biblionumber FROM issues LEFT JOIN items USING (itemnumber) WHERE date_due < NOW() \G; 2.2. Copy the barcode from the last entry 3. Set up so that you can run fines.pl and check in the item at the same time (or very close to the same time) 3.1. In Koha, click the "Check in" option in the search bar at the top of the page 3.2. Paste the barcode in the search bar BUT DO NOT PRESS ENTER OR THE ARROW RIGHT AWAY 3.3. In a terminal, enter the fines.pl command ./misc/cronjobs/fines.pl 3.4. Execute the command and immediately click on the arrow in the staff interface to check in the item 4. Check the patron's fines 4.1. Click on the patron's name in the check in screen 4.2. Go to the Accounting tab on the left 4.3. In the search box just above the table, paste in the returned item's barcode --> Without the patch, there are two fines, one Fine (Accruing) and one Fine (Returned) for the same item at the same time --> With the patch, there is only one fine, Fine (Returned) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Sam Lau <samalau@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #152987|0 |1 is obsolete| | --- Comment #37 from Sam Lau <samalau@gmail.com> --- Created attachment 152991 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=152991&action=edit Bug 18855: Don't create duplicate overdue fines if an issue is returned This includes Jonathan's followup If cronjobs/fines.pl is running during circulation hours, then an issue may be considered for having it's overdue fine updated after the issue has been returned and it's fine status flipped from 'UNRETURNED' to 'RETURNED'. In this case UpdateFine will create a duplicate fine because it can't find the specific accountline for the (formerly) overdue issue. This changes cronjobs/fines.pl to double check the issue before updating the fine. If the issue has changed between starting the script and updating the fine, then the script will skip it. There is a small amount of time between the check and calling UpdateFine where the issue can be changed and this problem can reoccure. The chance of that happening is so small that it's probably fine to leave as is. It is also possible that the fine won't be updated because the issue was returned. In this case the fine payed by the patron will be lower, but that is better then the patron finding later that there is more to a fine they thought they had paid all of. Test plan (by Caroline): 0. Preliminary settings 0.1. finesMode system preference must be set to Calculate and charge 0.2. There must be a circulation rule that will charge fines (beware of bug 32271) 0.3. In Tools > Calendar, today must not be a holiday 1. Make a lot of overdue checkouts - I used the batch checkout feature, but if your system already has a lot of overdue checkouts, you can skip to step 2 1.1. Enable batch checkouts 1.1.1. Go to Administration > Global system preferences 1.1.2. Search for BatchCheckouts 1.1.3. Set BatchCheckouts to Allow 1.1.4. Select all categories in BatchCheckoutsValidCategories 1.1.5. Click "Save all Circulation preferences" 1.2. Get a list of barcodes 1.2.1. Go to Reports 1.2.2. Click "Create from SQL" 1.2.3. Give the report a name 1.2.4. For the SQL query, enter SELECT barcode FROM items WHERE onloan IS NULL LIMIT 60; 1.2.5. Click "Save report" 1.2.6. Click "Run report" 1.2.7. Click "Download" > "Tab separated text" 1.3. Go to a patron's file 1.3.1. Go to Patrons 1.3.2. Click on "Search" 1.3.3. Click on a patron's name 1.4. Do a batch checkout with a due date in the past 1.4.1. Click on the "Batch check out" tab on the left 1.4.2. In "Use a file", click "Choose file" 1.4.3. Choose the file downloaded from the report 1.4.4. In "Hard due date", choose a date in the past 1.4.5. Click "Check out" 1.4.6. Click "Checkout or renew" 2. Find the last issue in the database 2.1. In the database (or in reports), type the following query SELECT issues.*, items.itype as itemtype, items.homebranch, items.barcode, items.itemlost, items.replacementprice, items.biblionumber FROM issues LEFT JOIN items USING (itemnumber) WHERE date_due < NOW() \G; 2.2. Copy the barcode from the last entry 3. Set up so that you can run fines.pl and check in the item at the same time (or very close to the same time) 3.1. In Koha, click the "Check in" option in the search bar at the top of the page 3.2. Paste the barcode in the search bar BUT DO NOT PRESS ENTER OR THE ARROW RIGHT AWAY 3.3. In a terminal, enter the fines.pl command ./misc/cronjobs/fines.pl 3.4. Execute the command and immediately click on the arrow in the staff interface to check in the item 4. Check the patron's fines 4.1. Click on the patron's name in the check in screen 4.2. Go to the Accounting tab on the left 4.3. In the search box just above the table, paste in the returned item's barcode --> Without the patch, there are two fines, one Fine (Accruing) and one Fine (Returned) for the same item at the same time --> With the patch, there is only one fine, Fine (Returned) Signed-off-by: Sam Lau <samalau@gmail.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #152991|0 |1 is obsolete| | --- Comment #38 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 153012 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=153012&action=edit Bug 18855: Don't create duplicate overdue fines if an issue is returned This includes Jonathan's followup If cronjobs/fines.pl is running during circulation hours, then an issue may be considered for having it's overdue fine updated after the issue has been returned and it's fine status flipped from 'UNRETURNED' to 'RETURNED'. In this case UpdateFine will create a duplicate fine because it can't find the specific accountline for the (formerly) overdue issue. This changes cronjobs/fines.pl to double check the issue before updating the fine. If the issue has changed between starting the script and updating the fine, then the script will skip it. There is a small amount of time between the check and calling UpdateFine where the issue can be changed and this problem can reoccure. The chance of that happening is so small that it's probably fine to leave as is. It is also possible that the fine won't be updated because the issue was returned. In this case the fine payed by the patron will be lower, but that is better then the patron finding later that there is more to a fine they thought they had paid all of. Test plan (by Caroline): 0. Preliminary settings 0.1. finesMode system preference must be set to Calculate and charge 0.2. There must be a circulation rule that will charge fines (beware of bug 32271) 0.3. In Tools > Calendar, today must not be a holiday 1. Make a lot of overdue checkouts - I used the batch checkout feature, but if your system already has a lot of overdue checkouts, you can skip to step 2 1.1. Enable batch checkouts 1.1.1. Go to Administration > Global system preferences 1.1.2. Search for BatchCheckouts 1.1.3. Set BatchCheckouts to Allow 1.1.4. Select all categories in BatchCheckoutsValidCategories 1.1.5. Click "Save all Circulation preferences" 1.2. Get a list of barcodes 1.2.1. Go to Reports 1.2.2. Click "Create from SQL" 1.2.3. Give the report a name 1.2.4. For the SQL query, enter SELECT barcode FROM items WHERE onloan IS NULL LIMIT 60; 1.2.5. Click "Save report" 1.2.6. Click "Run report" 1.2.7. Click "Download" > "Tab separated text" 1.3. Go to a patron's file 1.3.1. Go to Patrons 1.3.2. Click on "Search" 1.3.3. Click on a patron's name 1.4. Do a batch checkout with a due date in the past 1.4.1. Click on the "Batch check out" tab on the left 1.4.2. In "Use a file", click "Choose file" 1.4.3. Choose the file downloaded from the report 1.4.4. In "Hard due date", choose a date in the past 1.4.5. Click "Check out" 1.4.6. Click "Checkout or renew" 2. Find the last issue in the database 2.1. In the database (or in reports), type the following query SELECT issues.*, items.itype as itemtype, items.homebranch, items.barcode, items.itemlost, items.replacementprice, items.biblionumber FROM issues LEFT JOIN items USING (itemnumber) WHERE date_due < NOW() \G; 2.2. Copy the barcode from the last entry 3. Set up so that you can run fines.pl and check in the item at the same time (or very close to the same time) 3.1. In Koha, click the "Check in" option in the search bar at the top of the page 3.2. Paste the barcode in the search bar BUT DO NOT PRESS ENTER OR THE ARROW RIGHT AWAY 3.3. In a terminal, enter the fines.pl command ./misc/cronjobs/fines.pl 3.4. Execute the command and immediately click on the arrow in the staff interface to check in the item 4. Check the patron's fines 4.1. Click on the patron's name in the check in screen 4.2. Go to the Accounting tab on the left 4.3. In the search box just above the table, paste in the returned item's barcode --> Without the patch, there are two fines, one Fine (Accruing) and one Fine (Returned) for the same item at the same time --> With the patch, there is only one fine, Fine (Returned) Signed-off-by: Sam Lau <samalau@gmail.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #39 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Pushed to master for 23.11. Nice work everyone, thanks! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #40 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Thanks for all the hard work! Pushed to 23.05.x for the next release -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18855 --- Comment #41 from Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com> --- Nice work everyone! Pushed to oldstable for 22.11.x -- You are receiving this mail because: You are watching all bug changes.