[Koha-devel] Branch Specific System Preferences

Thu May 10 09:46:49 CEST 2012

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 at bywatersolutions.com

On Thu, May 10, 2012 at 3:47 AM, Ian Walls <koha.sekjal at 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 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
>>>
>>
>>
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120510/e237dd18/attachment.htm>