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 r...@bywatersolutions.com On Thu, May 10, 2012 at 3:47 AM, Ian Walls <koha.sek...@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.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/ >
_______________________________________________ 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/
