[OPEN-ILS-DEV] Fine Generation Code Question

[Jason Stephenson]

Quoting Dan Wells <dbw2 at calvin.edu>:

> Hello all,
>
> I've been mucking about in the fine code and getting a bit  
> frustrated, so I'm looking for input before I move ahead.
>
> As it stands, fine generation is part of the storage API.  As such,  
> when it is called during checkin, it runs in its own transaction  
> (independent of the circ/copy transaction).  The issue is that  
> (increasing) various pieces of the circ code also mangle handle  
> fines, particular the lost item related code, and any code related  
> to voiding/zeroing balances.
>
> I think we have two (not necessarily exclusive) paths to move forward:
>
>
> 1)      Move the fine generation code into open-ils.circ and rewrite  
> the necessary bits to use cstore.  This would at least bring in the  
> possibility of having all the checkin-time fine handling done in the  
> same transaction, and thus give us a lot of flexibility in how we  
> structure things.
>
> 2)      Refactor the code so that more (or all) fine handling (not  
> just generation, but lost bill processing, voiding, etc.) happens  
> *after* the checkin transaction rather than during.

I attempted to do some of the above with my "conditional negative balances"
branch.

I noticed a couple of things while working on that:

There were at least two functions called to generate/calculate overdue
and/or lost fines.

If you're doing a renewal, the fine generation is actually run twice,
once in the renewal code and one in the checkin code. The flow is:

1. Call renewal code
2. do some stuff
3. Calculate fines
4. call checkin
5. do some stuff
6. call checkout

I had to run it with the debugger to make that obvious, but if you
look at the code hard enough, you'll see it.

I'd honestly like to refactor everything under OpenILS/Application/Circ
including holds, billing, and the circulation code.

>
> I'm leaning toward #1 under the hope that it would mean fewer  
> changes overall, but there are certainly merits to #2.  Does anyone  
> see anything in particular to suggest we should instead pursue #2  
> exclusively?

As you found on lp 1393533, there is not a simple solution to this issue.
The circ and billing code are very complex and highly intertangled. I
think the best solution is to disentangle the code and simplify the flow.
In my mind, that means heavy refactoring.

>
> Thanks for any input.
>
> Sincerely,
> Dan
>
>
> Daniel Wells
> Library Programmer/Analyst
> Hekman Library, Calvin College
> 616.526.7133


-- 
Jason Stephenson
Assistant Director for Technology Services
Merrimack Valley Library Consortium
1600 Osgood ST, Suite 2094
North Andover, MA 01845
Phone: 978-557-5891
Email: jstephenson at mvlc.org