Kyle Hall, Development Support Specialist, ByWater Solutions
Rewrite of accounts management. Payments and fees now in separate tables; a third table tracks the interaction between the two. Can’t tell in current Koha what payment affected a given fee.
A lot more data now available and displayed; print receipt for individual fee or payment. Payments can be viewed separately; fees can be viewed separately. Description now links to the item data, not just barcode and title.
By default, can hide fees and payments that have no balance.
Can now see each and every fee paid.
OPAC view is similar, so patrons will also be able to see their fees and payment history — very similar to staff side view.
Development is still under progress.
Write now, credits sit there forever, fees and credits added together to give a balance. Now, credits automatically pay off fines and fees until outstanding balance reaches zero. Tracks what fees were paid with that credit.
Biggest thing from doing this development? Kyle admits he made a huge mistake. Much better to do small, incremental changes in the community, rather than a big, huge change.
It’s gone to the signed off stage, and no one has dived into QA’ing yet. May need to redo the entire development and do it piece by piece until it resembles the development where it stands today.
Testing a large change at once, takes time. Fear you can miss something. Double-QA suggested for this. No one in QA has stepped up to do this. Different approaches to QA, based on background: Developer QA will look at code in patch and suggest code rewrites; most systems librarians are just trying to break the feature. But at the end, the QA process has same end goal: try to make sure feature/patch works and that it doesn’t break anything else in Koha.
Part of this process is that Koha is constantly changing as things are developed — coding changes, new features added simultaneously, etc., so your code/patch may need to be redone to reflect those changes.
Koha is a gift with expectations.Â
Questions about QA process, too stringent? Discussion around how Koha used to be before stringent QA process put into place — wild west. Pretty stable now; developments may take longer to get in, but system is more stable, as a result.
Koha works in many different ways, for many different libraries, don’t trample over all types of libraries workflows.
Suggestion made, could part of a development contract, include paying for for someone’s QA time? Hot issue, you don’t want to necessarily pay someone for a rubber stamp; Horowhenua Koha community foundation hiring for community QA and signoffs.
Kyle is working on larger developments now, breaking it down into pieces, his biggest lesson learned from the accounts rewrite.
Will he truly start over? Not sure yet; if he does take it apart and start over, algorithms can be reused, his knowledge on how this feature all works. May piece out into individual bugs. Can’t easily and quickly take what he’s done immediately into pieces, but won’t take nearly as long to write.
The cataloging module feature, doesn’t touch most of Koha. Almost completely independent. It’s huge, but isn’t affecting most of existing Koha, like the fines module does.