Dear Jesse & Fellow List Members: This new script sounds great! We would - very much - like to see it deployed for 3.0, a version which we are committed to deploying as soon as the stable version is released. The old version is unwieldy and tricky, the fact that using defaults is broken is unhelpful too! One thing which we are specifically interested in knowing is if it will handle incrementing fines daily as opposed to lumpsums periodically? Best, Petrus Hanover koha-devel-request@nongnu.org wrote:
Send Koha-devel mailing list submissions to koha-devel@nongnu.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.nongnu.org/mailman/listinfo/koha-devel or, via email, send a message with subject or body 'help' to koha-devel-request@nongnu.org
You can reach the person managing the list at koha-devel-owner@nongnu.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Koha-devel digest..."
Today's Topics:
1. Re: Issuing Rules (Galen Charlton)
----------------------------------------------------------------------
Message: 1 Date: Tue, 19 Feb 2008 10:18:19 -0600 From: "Galen Charlton" <galen.charlton@liblime.com> Subject: Re: [Koha-devel] Issuing Rules To: Jesse <pianohacker@gmail.com> Cc: Koha Development Mailing List <koha-devel@nongnu.org> Message-ID: <4659947d0802190818l47f9e189g1f5244ab9201ffe0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
Hi,
On 2/18/08, Jesse <pianohacker@gmail.com> wrote:
My little script (attached, along with a template for the default set) is actually a replacement for issuingrules.pl. Instead of having a massive table with two cells for every combination of itemtype and category code, there is now just one row for each rule; if you have a default rule, and rules for DVDs and Nonfiction, you will have three rows, with a cell each for Fine Amount, First Remind, Amount Loanable, etc. This is a rather large change, but it makes defining issuing rules much simpler.
I did a (very) quick port of this to 3.0 and took a look. I like the idea of removing the big matrix, particularly for libraries that have lots of item types and/or patron categories. I also like the fact that it doesn't require the user to enter commas or remember what each comma-delimited field means. I think this approach will make it much easier to add additional fields to the issuing rules and manage them in the UI.
Some suggestions:
* Add the ability to limit one's view by item type or patron category. * Either sort the item types and patron categories by the description or include the code so that it is clear how the entries are being sorted. * Somehow make clear what the default issuing rule is for a given branch, item type, and patron category combination if it's not explicitly specified -- perhaps by allowing for wildcard entries.
I would be in favor of getting this into 3.0 or 3.x quickly, possibly making it a parallel alternative to the existing issuingrules.pl for a while.
Regards,
Galen
Actually, this script only handles the rule creation part of it, not the rule usage. However, I did have an idea (not yet implemented, but I will soon) for fixing those as well. The rules are documented as follows:
* same branch and same borrower category, itemtype * * same branch and same itemtype, borrower category * * same itemtype and borrower category, branch * * everywhere * If nothing is set, default is 21,5 (hardcoded)0
However, GetLoanLength is the only part of Koha that actually implements these, and clumsily at that. We can reduce those 9 selects to a single one, using a stored function:
CREATE FUNCTION specificity(categorycode CHAR(2), itemtype VARCHAR(6), branchcode VARCHAR(4)) RETURNS INTEGER NO SQL RETURN (IF(categorycode != '*', 7, 0) + IF(itemtype != '*', 5, 0) + IF(branchcode != '*', 9, 0));
This calculates how specific a given issuing rule is, given what it specifies. For instance, a rule that defines a branch and category has a specificity of 16, while a rule that defines a branch and itemtype has a specificity of 14. The numbers are somewhat arbitrary, and are mainly used because they get what the documentation says should be gotten. Thus, GetLoanLength's SQL can become:
SELECT issuelength FROM issuingrules WHERE categorycode IN (?, '*') AND itemtype IN (?, '*') AND branchcode IN (?, '*') ORDER BY specificity(categorycode, itemtype, branchcode) DESC LIMIT 1;
This can be adapted for GetIssuingRules, CanBookBeIssued and TooMany merely by changing the returned columns. I know that there isn't any precedent for stored functions in Koha, but this solves the problem with a minimum amount of fuss. It is also entirely separate from smart-rules.pl, though specificity() could be useful for sorting the list of rules. -- Jesse
Petrus, I'm certain this script won't handle incrementing fines daily. That is handled by a cron job. I also would like to see the fines incremented daily. I saw mention of such a feature in the Koha 3 install I have here, but couldn't find the corresponding cron job. In my Koha 2.2 install I have made my own fines2.pl that runs in cron once a day and increments the fines. On Tue, 2008-02-19 at 14:27 -0500, Petrus B. van Bork wrote:
Dear Jesse & Fellow List Members:
This new script sounds great! We would - very much - like to see it deployed for 3.0, a version which we are committed to deploying as soon as the stable version is released. The old version is unwieldy and tricky, the fact that using defaults is broken is unhelpful too! One thing which we are specifically interested in knowing is if it will handle incrementing fines daily as opposed to lumpsums periodically?
Best,
Petrus Hanover
participants (3)
-
Jesse -
Michael Hafen -
Petrus B. van Bork