[Koha-devel] Branch Specific System Preferences

[Ian Walls]

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 at 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 at foundations.edu> wrote:
>
>> Hi Ian,
>>
>> On Thu, Mar 22, 2012 at 1:25 PM, Ian Walls <koha.sekjal at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120509/0526d054/attachment-0001.htm>