Bug 17483 - Forgiving charge should apply to item's last fine.
Summary: Forgiving charge should apply to item's last fine.
Status: CLOSED WORKSFORME
Alias: None
Product: Koha
Classification: Unclassified
Component: Fines and fees (show other bugs)
Version: 18.05
Hardware: All All
: P5 - low minor (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-21 15:49 UTC by Blou
Modified: 2020-11-30 21:44 UTC (History)
11 users (show)

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


Attachments
Bug 17483 - Forgiving charge should apply to item's last fine. (2.07 KB, patch)
2016-10-21 15:59 UTC, Blou
Details | Diff | Splinter Review
Bug 17483: Forgiving charge should apply to item's last fine. (2.03 KB, patch)
2018-07-27 18:18 UTC, Maryse Simard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Blou 2016-10-21 15:49:36 UTC
When returning an item with a fine, if the Forgive checkbox is clicked, this forgives the first accountline associated to the item/user, not the current/latest as it should.

Scenario (Real world):
- A patron returns a book late, ensuring a 5$ fine.  Does not pay it.
- The patron borrows the book again 3 months later.  Gets late again, and fined 2$.
- Great timing: The library offers amnesty for a week.  Bring back your book and we'll forget that they're late.
- On checkin, the librarian clicks "Forgive overdue charges" and scan the book.
- Koha cancels the 3-months-ago 5$ fine.
Comment 1 Blou 2016-10-21 15:59:11 UTC
Created attachment 56725 [details] [review]
Bug 17483 - Forgiving charge should apply to item's last fine.

When returning an item with a fine, if the Forgive checkbox is clicked, this forgives
the first accountline associated to the item/user, not the current/latest as it should.

Scenario (Real world):
- A patron returns a book late, ensuring a 5$ fine.  Does not pay it.
- The patron borrows the book again 3 months later.  Gets late again, and fined 2$.
- Great timing: The library offers amnesty for a week.  Bring back your book and we'll forget that they're late.
- On checkin, the librarian clicks "Forgive overdue charges" and scan the book.
- Koha cancels the 3-months-ago 5$ fine.

Test scenario:
- Find a user with an unpaid fine (accounttype = 'FU' in db) on a returned item.
- Checkout the same item for the same user.
- CHOICE 1: - Force it being late by modifying the date_due to last year.
            - Run fines.pl to generate another fine.
- CHOICE 2: - Create directly another accountlines entry in the DB with the same info
            - You may change the amounts to help differentiate
- Go to the returns.pl screen, check the Forgive checkbox.  Return the item.
- Look at the DB, the first line got paid.  Not the latest one.
- APPLY THE PATCH
- Redo scenario, this time the latest entry (by the timestamp column) is paid.
Comment 2 Alex Buckley 2017-08-02 23:31:11 UTC
Hi Blou

I ran through your test plan and your patch works fine, however I notice on the current master branch the latest overdue fine gets paid correctly as well, and so I wonder if this patch is necessary?
Comment 3 Maryse Simard 2018-07-27 18:18:03 UTC
Created attachment 77311 [details] [review]
Bug 17483: Forgiving charge should apply to item's last fine.

When returning an item with a fine, if the Forgive checkbox is clicked, this forgives
    the first accountline associated to the item/user, not the current/latest as it should.

    Scenario (Real world):
    - A patron returns a book late, ensuring a 5$ fine.  Does not pay it.
    - The patron borrows the book again 3 months later.  Gets late again, and fined 2$.
    - Great timing: The library offers amnesty for a week.  Bring back your book and we'll forget that they're late.
    - On checkin, the librarian clicks "Forgive overdue charges" and scan the book.
    - Koha cancels the 3-months-ago 5$ fine.

    Test scenario:
    - Find a user with an unpaid fine (accounttype = 'FU' in db) on a returned item.
    - Checkout the same item for the same user.
    - CHOICE 1: - Force it being late by modifying the date_due to last year.
                - Run fines.pl to generate another fine.
    - CHOICE 2: - Create directly another accountlines entry in the DB with the same info
                - You may change the amounts to help differentiate
    - Go to the returns.pl screen, check the Forgive checkbox.  Return the item.
    - Look at the DB, the first line got paid.  Not the latest one.
    - APPLY THE PATCH
    - Redo scenario, this time the latest entry (by the timestamp column) is paid.
Comment 4 Maryse Simard 2018-07-27 18:22:25 UTC
I tested on the current master and the error still occurs, which means this patch is still needed.
Comment 5 Martin Renvoize 2019-04-09 06:20:14 UTC
I can't replicate this...  I can't see how one can manage to get two 'FU' state fines on the item to be able to come up with the scenario where the older fine would be picked.

Could you clarify what settings you are using for fines so we can more accurately replicate this before I signoff on it. (at this point it's a case of 'does no harm, does no good' for me)
Comment 6 Martin Renvoize 2020-02-11 12:41:51 UTC
OK, tried again and still can't replicate this one.. I'm going to close it with WORKSFORME.. if you can still replicate it please open a new bug with a reproducible test plan.