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.sek...@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 < > cnighswon...@foundations.edu> wrote: > >> Hi Ian, >> >> On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sek...@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/
