[Koha-devel] An idea for revamping the issuing rules

[David Cook]

I don't actually have anything substantive to add to this conversation.

Just +1 for a revamped circulation rules editor. 

-----Original Message-----
Message: 2
Date: Mon, 25 Nov 2013 11:44:12 -0500
From: Kyle Hall <kyle.m.hall at gmail.com>
To: Galen Charlton <gmc at esilibrary.com>
Cc: Koha Devel <koha-devel at lists.koha-community.org>
Subject: Re: [Koha-devel] An idea for revamping the issuing rules
	system
Message-ID:
	<CACpVHfzdmP0tiR6Vr2Y2ApF7trOCV23odOE9N1AAj_foPckt9w at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

>
> As Jonathan has mentioned, I've expressed my concerns about a similar
> proposal to drop the FK relationships in the discussion in bug 8369, and I
> also think that any scheme to refactor the storage of the circ rules must
> provide a concrete, user-visible improvement.  Just reducing the number of
> table involved is not an adequate reason.
>

Yes, I would assume a revamped circulation rules editor would be
sufficient?


>
> That said, the FKs are only one consideration.  Being able to set a
> general rule for one part of the circ policy (in your example, the loan
> length) that more specific rules that cover another part (in your example,
> the maximum number of loans) can fall back on is a change that I *would*
> see being beneficial: it would allow for circulation policies to be
> expressed more concisely.
>

Agreed!


> A rule_name/rule_value approach to this, however, may have a
> maintainability problem: how do you deal with adding a new rule type in
the
> future?  I'd suggest, instead, a scheme where a NULL value in a column
such
> as issuelength signals that the next more general rule should be
consulted.
>

Do you mean type is in "maxholds" or "issuelength"? In that case, it would
be as simple as create one or more rules with that "rule_name". A fully
optional rule can simply be left to non-existence. In my mind, I instead of
having rules with a NULL value, they simply would not exist. Does that make
sense? Or is it that you mean ccode/branchcode should use NULL instead of *
with full key constraints? I think that is an absolute must.


>
> Any scheme to do a major refactoring of the circ rules must, in my view,
> cover all of the following bases:
> * a well-defined upgrade path that guarantees that there is no change to
> effective circulation policy
>

Agreed, I don't think this would be a difficult one to cover, though it
would not simply the rules for those upgrading. They would have to trim
their rules by hand, but it would at least mean no change in behavior.


> * as always, adequate unit test coverage
>

Absolutely!


> * attention to the user interface for defining circ policy -- if the point
> of a refactoring is to make it easier to manage circ policies, the UI
> *must* reflect that
>

Indeed, this is almost the crux of the issue. I foresee a new for a new
paradigm in how to visually represent the circulation policies. Maybe
instead of the rules being branch-centric as they are now, they should be
rule-centric? Perhaps even a tabbed interface with a tab for each rule?


> * ideally, some prototyping of that UI first to check any assumptions that
> the new version is actually easier to manage
>

Agreed. I think at least some drawings of a general design would be a good
start.

Kyle