[Koha-devel] Branch Specific System Preferences

[Ian Walls]

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/20120322/6cbb454d/attachment.htm>