[Koha-bugs] [Bug 16223] Automatically remove any borrower debarments after a payment

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16223

Katrin Fischer <katrin.fischer at bsz-bw.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Signed Off                  |Failed QA

--- Comment #40 from Katrin Fischer <katrin.fischer at bsz-bw.de> ---
Hi Emmi, 

thanks for the rebase, starting to dig a little deeper into this now:

1) DelDebarmentsAfterPayment 

According to coding guidelines the methods in Koha namespace should always be
snake case.

2) Terminology

debarment --> restriction

In general, and that possibly applies to above as well, we should use the term
"restrictions". See: bug 5268 for an explanation.

borrower --> patron

I know you can't change all spots as the table is called borrowers_debarments,
but I think it would be good to change whereever possible.

Example:
Lift these debarments after Borrower has paid their charges >
Lift these restrictions after a patron has paid their charges

See also: https://wiki.koha-community.org/wiki/Terminology

3) Number of tests

The number of tests needs to be updated to 37 for tests to pass :)

4) Functionality

A thing I stumbled on is that this works on the restriction comment and not the
type of restriction. I believe this is done, because we can't have different
types of restrictions currently and this makes it more flexible. But I am not
sure if it will not also create issues.

Currently the comment can only be set, if the type of restriction is MANUAL,
for DISCHARGE it will be empty, possibly for OVERDUES and SUSPENSION as well.
We cannot edit restrictions to add a certain comment or fix a typo.

I recently reviewed bug 23681 and I think this goes in a more maintainable
direction. It will allow to define restriction types in a new table with some
being Koha-internal and others being added in addition. 

And what you do with the YAML pref could then be moved to be columns in the new
table, which would make it easy to query, easy to handle for staff, etc. and
remove any issues with variations of spelling/whitespace by having a list to
pick from.

I know this is the older dev, but maybe have a look at bug 23681?

It's currently waiting for some more work, but I think it would be still
achievable for the next version, especially with a little help.

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