[Koha-bugs] [Bug 29012] Some rules are not saved when left blank while editing a 'rule' line in smart-rules.pl

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

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

--- Comment #26 from Andrew Nugged <nugged at gmail.com> ---
Those who installed this on production will get issues with the
circulation_rules table because of atomic update. So:


On smart-rules.pl (Home > Administration > Circulation and fine rules):
we have 5 tables:

    1. Defining circulation and fine rules for all libraries
       (... for XXX branch, if branch selected)
    2. Default checkout, hold and return policy
       (... for XXX branch, if branch selected)
    3. Checkout, hold policy by patron category 
       (... for XXX branch, if branch selected)
    4. Lost item fee refund on return policy
       (... for XXX branch, if branch selected)
    5. Holds policy by item type
       (... for XXX branch, if branch selected)

and with dropdown, we can select rules for "Standard rules for all libraries"
or switch to ANY of the available branches represented by the whole page.

THE ISSUE:

... and this atomic update was intended to add "empty strings" and "zeroes" to:
issuelength, hardduedate, unseenrenewalsallowed, rentaldiscount,
decreaseloanholds values,

and the intention of atomuc update looks like was to select ANY combination of
branch/itemtype/category of else in DB, then for those, we should add those
"zeroes" and "empty strings". Like it was "some rows in table 1 if only, then
we add empty/zeroes".

But those "any combination" also covers rules belonging NOT just to table 1 but
also to tables 2..5, so if you don't have any rule for BRANCH in table 1 but
you had something for the branch in tables 2,3,4,5 this atomic update adds
orphan values for 'issuelength', 'hardduedate', 'unseenrenewalsallowed',
'rentaldiscount', 'decreaseloanholds'.

And, EVEN WORSE: because those rules even will not be shown for the operator as
RULES in table 1, but they still affect the results in circulation analysis as
bigger priority rules than those without branches (i.e. "*"/all) so zero or ''
value will be used as rule result for calculations.

And nothing will be shown to the operator (!!!).

For example, we just had on our production having "issuedate" "0" for some
branches added by this atomic update because those branches had 'holdallowed'
settings in table 5 (but nothing in table 1 in that per-branch-page!). But rule
became efficient for all requests and made a real mess when borrowers had
"today" issue return date & loan length (!!!). More complexity: this now can be
fixed only by manually removing trash from circulation_rules but requires
analysis, argh!

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