SPIKE: MSU patron not billed overdue for recalled item upon checkin

SPIKE to investigate what's going on here to start

Overview: The primary issue is that a recalled item had a due date of October 23 and item was returned on December 5. The patron was not billed an overdue fine but should have been billed $1.00 per day for the days the library was opened. A secondary issue is that the renewals and recall of this item did not change the due date. It remained October 23. That seems odd to me, but I am not a loan expert. Depending on what the dev discovers, we may need to change the overdue fine process to calculate overdues using the most recent renewal date (if there is one) from the loan 'action' record rather that Due date. Holly will make a separate JIRA for this if it is needed. (Never mind the secondary issue. A recall not changing the due date when an item is already overdue is a known issue. It is functioning as originally specified. There is an enhancement in JIRA for a configuration option to change due date when recalling an overdue item. The multiple 'renewed' actions are artifacts of updating the loan record via the loan-storage API endpoint, and, at least as far as Brooks understands, should not have actually changed the due date, either, as they didn’t touch the BL APIs.)

Important Information: MSU has had recalled fines assessed properly in the past on loaned items that were associated with the correct Overdue Fine Policy upon checkout (which is what normally happens). The loan he is reporting the error with was part of a first batch of loans MSU had to 'correct' the Overdue Fine Policy for via API (this was done two weeks ago). This is the first of that batch of loans that was returned late after being recalled. Brooks is wondering if there is any data, other than what is listed below, considered when processing overdue loans?

• Loan Data: due date and returned date
• Loan Policy (as set in Loan Data): grace period
• Overdue Fine Policy (as set in Loan Data): all settings

Details from Slack conversation:

• Brooks asked Holly what was supposed to happen with recalled items that were returned late, and I explained that the Overdue recall fine from the Overdue Fine Policy in effect would be charged at check-in for the days from the due date to the returned date (ignoring closed days if Count closed days/hours/minute is set to "No").
• Brooks then Slacked: "That’s what I thought. I have a specific case in our environment where that didn’t happen. This is a loan where we had to go in and “correct” the associated overdue fine policy via API a couple weeks ago after discovering a circulation rules misconfiguration. The due dates were not modified. The item was due on 10/23 and returned on 12/5. It was recalled on 11/17, with a 7 day return interval. It had been renewed twice. We were closed 11/25, 11/26, and 11/27. My understanding is that recall fines should have been charged from 10/23, up to the maximum, when the item was checked in. Thoughts?"
• Holly then asked Brooks for screen prints of the Calendar for the Service point, the Overdue Fine Policy in effect and the Loan Details for the loan. The screen prints are all attached.
• Cate then Slacked: "If you can't figure this out by looking at it, you might want to run it by bohdan-suprun. He has recently looked at the "dueDateChangeByRecall" flag and how it gets set as part of CIRC-1003.
• Holly's response to Brooks: "It looks like the patron was not charged any overdue fines. I would have expected the patron to be charged the recall overdue fine only from the last time the item was renewed (Nov 11/17) until it was returned (12/5), except that I noticed that the Due Date wasn't changed from 10/23/2020. How does the patron know when the item is due after a renewal if the Due Date doesn't change? Does the Loan Policy have a Grace Period? If so, what is it?"
• Brooks again: "Here’s the calendar, and the loan policy has a grace period of 1 day and a recall return interval of 7 days. The 11/17 activity is the result of me editing the overdue fine policy on the loan via the loan-storage API to correct an error in the circulation rule that was originally applied to the loan."
• Holly again: "I am going to create a JIRA bug for this. I am thankful to you for reporting this issue. I tried to get sites to test overdue fines for me using their own data, but was not successful. I knew that what was delivered could not possibly be perfect as is. Code just doesn't work that way. I just had to wait for someone to use overdue fines to find the odd cases that don't work correctly. That someone is you."
• Brooks again: "Which was not the expected behavior. Mostly, I’m wondering what the algorithm is for evaluating a loan at check-in to determine if fines should be assessed? We’ve had recall fines assessed in the past on items that received the correct policy during the initial checkout. This is the first of the group of loans that I updated via API to have the “correct” overdue policy that has been returned late after being recalled, and I’m wondering if anything other than the due date, loan, and overdue policies are considered (ie. the loan metadata and activity log)."
• Holly again: "I don't know about that, but I will include this information in the bug ticket. What should have happened is that the patron should have been charged the recall overdue rate from the Due Date to the Returned Date (which would have been odd, given the Due Date remained at the original due date after the renewals, but that is what is coded to should happen). I will make you a 'Watcher' on the bug..."
• Brooks again: "Thanks. Yeah, from what I can tell, every time the loan JSON is updated in loan-storage, it creates activity entry, and the only thing that was updated on those “renewals” was the overdue policy id. The “action” did not change, so it just recorded the most recent one again."