| Summary: | Patron categories noissuescharge values default to 0 when not set | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Nick Clemens (kidclamp) <nick> |
| Component: | Patrons | Assignee: | Nick Clemens (kidclamp) <nick> |
| Status: | In Discussion --- | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | aude.charillon, caroline.cyr-la-rose, gmcharlt, katrin.fischer, kyle |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41404 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20338 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38704 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25219 |
||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Attachments: | Bug 41405: Treat blank value as unset | ||
Created attachment 190308 [details] [review] Bug 41405: Treat blank value as unset Maybe this is actually invalid?
The code that checks these in Koha::Patron::is_patron_inside_charge_limit uses:
3512 my $no_issues_charge = $patron_category->noissuescharge || C4::Context->preference('noissuescharge');
3513 my $no_issues_charge_guarantees =
3514 $patron_category->noissueschargeguarantees || C4::Context->preference('NoIssuesChargeGuarantees');
3515 my $no_issues_charge_guarantors_with_guarantees = $patron_category->noissueschargeguarantorswithguarantees
3516 || C4::Context->preference('NoIssuesChargeGuarantorsWithGuarantees');
3517
So if they are 0 they don't matter?
I don't think it is supposed to work this way though - based on 41404 and the way NoIssuesCharge seems to work a 'blank' is "There is no limit" and Zero should be "Any fines should block issues"
Hi Nick, I am following your plan from the description and I am seeing the same behaviour. In Administration->Patron categories->Edit, the wording for Checkout charge limit is "If set, this will override the global value set in the noissuescharge system preference." So I agree with you that there's a problem: for me "if set" means "if this box isn't blank". A "0.00" value should mean that if patrons have more than 0.00 in fines, they can't checkout. This is not currently the case. (The Koha Manual is down right now, so I can't check if there are any subtleties I am missing.) What I am seeing when testing is this: 1) I have patron A in category ST. For category ST I followed your steps up to 8. I have patron B in category PT. I did not amend PT. 2) Both have fines of 2.50. The noissuescharge sys pref is set to its KTD default of 5. 3) Both patrons can checkout - even though the ST category has Checkout charge limit set to 0. 4) If the ST category Checkout charge limit is set to 1, patron A cannot checkout. 5) If the ST category Checkout charge limit is not set to a unit (0.01, 1.5), the value is rounded to the nearest unit when saving (0.01 becomes 0; 1.5 becomes 2). Also: 6) If the noissuescharge sys pref is set to 0, patrons can still checkout. You have to set it to 0.00 for them not to be able to checkout. Do we amend the text in the patron category setting and the sys pref or can we correct the behaviour? |
To recreate: 1 - In a new KTD, check the values for a category: SELECT * FROM categories WHERE categorycode ='B'\G 2 - By default these three columns are null: noissuescharge: NULL noissueschargeguarantees: NULL noissueschargeguarantorswithguarantees: NULL 3 - If they are not, set them so: UPDATE categories SET noissuescharge=NULL, noissueschargeguarantees=NULL, noissueschargeguarantorswithguarantees=NULL; 4 - Open the category in staff interface: More->Administration->Patron categories->Edit 5 - Note the three inputs are set to 0 Checkout charge limit Guarantees checkout charge limit Guarantors with guarantees checkout charge limit 6 - Save the entry without making changes 7 - Check the DB as in Step 1 8 - Note all values are 0 9 - Edit and black the inputs and save 10 - Check the DB 11 - Note all value are now undef We should not have to edit the form to prevent changes