Ian, Looking at your RFC, extending this onto language-centric sysprefs for the block-HTML stuff would be pretty easy; add a column "language" to the table you propose. For things like circ rules, it would be NULL, as language is not a factor there...and for the blocks of HTML, some of your columns (like itemtype) would be NULL. +1 for this new table. *D Ruth Bavousett* Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software Headquarters: Santa Barbara, CA Office: Lawrence, KS Phone/Fax (888)900-8944 http://bywatersolutions.com ruth@bywatersolutions.com On Thu, May 10, 2012 at 3:47 AM, Ian Walls <koha.sekjal@gmail.com> wrote:
RFC up on the wiki: http://wiki.koha-community.org/wiki/Contextual_Preferences_RFC
It's pretty rough... I got about 2 hours of it written yesterday, then my IP changed and I lost all my text when trying to submit. This rewrite is simplified, with the hopes of expanding further later.
Another element I'm not sure how best to factor in: language. Especially for HTML blocks, it'd be handy to have a way to provide multiple options depending on the user's language. This isn't universally applicable to all preferences, only text-based values... thoughts?
-Ian
On Thu, Mar 22, 2012 at 3:46 PM, Ian Walls <koha.sekjal@gmail.com> wrote:
Chris,
I'm seeing the Contextual Preferences Engine (CPE) as a replacement to the issuingrules and related tables, first and foremost. It would be put in place, then be migrated into slowly over time by developers, since switching the subroutine calls from issuingrules and sysprefs to the CPE would be a good level change in a lot of different places. Users would not be able to contextualize a syspref on their own from the staff client; it would need to be a separate enhancement. The CPE just provides a unified platform for the developers to work with, making adding new context-sensitive behaviours easier to code.
One major bonus is that each rule is granular and independent of other rules. Instead of having to maintain a huge circ matrix of rules and exceptions and exceptions to exceptions, you define you base case, then the few things that are different can be made different. The tester page will let you quickly confirm which rules you'll be getting in any given situation, so if there is any unexpected behaviour, you can trace it out.
Rough implementation plan:
Create new table in DB Create interface to manipulate values in table (get basics of templates and subroutines in place) Create interface to test which rules are applied to any given combo of Branch, Patron and Itemtype
--- Up to here can be done behind the scenes without changing any other part of Koha ---
Migrate over issuing rules Spruce up interface now that there is data Begin changing Circ subroutines to use CPE instead of smart rules Migrate over some sysprefs that need further contextualization (see bug for some that have been identified)
--- much later ---
Drop the smart rules pages and database tables once the migration is complete and stable.
The first section could be completed by June very easily; that'd give us the CPE framework to work in, and it'd just be a matter of changing system calls to use it instead of whatever they're currently using. If that code is committed to master, then your need for per-branch SCO settings could be handled quickly before August. It would still need to wait until the next release in October before it's part of stable, but so would any kind of change like this.
I hope this makes sense. As I said, any assistance, either in design, implementation or both, is welcome. I've been meaning to do this for a long while, but other things (like testing Hourly Loans) have taken priority recently. I'd love to have this in place for 3.10, to some degree or another.
Cheers,
-Ian
On Thu, Mar 22, 2012 at 13:44, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Hi Ian,
On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sekjal@gmail.com>wrote:
Chris,
I've been meaning to write a Contextual Preferences Engine for Koha for a while now, to solve the problems we have with the Circ Matrix, as well as with global sysprefs that should really be more configurable.
The idea is that it will be a DB table with 5 main columns: Branch, Patron Category, Item Type, Key and Value. Any of the first 3 can be a specific value or "default". If a contextual preference doesn't make sense to factor in one of the 3 values, it'll be ignored.
Is the goal is to allow any or a defined set of system preferences to be "contextualized" based on branch, patron category, and/or item type?
This, along with a rewritten editor and rules tester tool, would solve a bunch of our customizability problems in one go, without necessarily introducing too much complexity for users (provided we make a good interface).
Agreed.
I hope to have a patch for this started after 3.8 releases (and all our DB revs are stable for a while). Any help would be welcomed.
Sounds good. I need this functionality to be in place by August of this year, so I'm very interested in getting started as soon as possible. I will be carving out time during my workday for it over the next several months.
Kind Regards, Chris
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/