[OPEN-ILS-DEV] Modifications to Circ Matrix Matchpoint checking
Thomas Berezansky
tsbere at mvlc.org
Fri Sep 10 23:03:53 EDT 2010
I believe I have completed work on this particular project. For those
interested here but not following launchpad, I submitted a patch there:
https://bugs.launchpad.net/evergreen/+bug/635463
Thomas Berezansky
Merrimack Valley Library Consortium
Quoting Mike Rylander <mrylander at gmail.com>:
> There as been a /lot/ of discussion surrounding this functionality on
> IRC over the last week, just to let everyone here know that it's not
> being ignored.
>
> More below.
>
> On Tue, Sep 7, 2010 at 4:29 PM, Thomas Berezansky <tsbere at mvlc.org> wrote:
>> My previous email included a patch that was, unfortunately, just the tip of
>> the iceberg, so to speak. I have since figured out a lot of what needs to be
>> done to do this on the backend.
>>
>> However, in looking at what needs to be done, I came up with several
>> questions as to how to handle things.
>>
>> Currently the circulation flag, duration rule, recurring fine rule, and max
>> fine rule are on my list of things to have "fall through".
>>
>> I am unsure as to whether or not to have the total copy hold ratio or the
>> available copy hold ratio values fall through or not. They are not
>> "endpoint" data, but at the same time may be considered to be an important
>> part of the checks.
>>
>> In that regard, I see three logical options:
>> 1 - Don't have them fall through. If they aren't set on the first matchpoint
>> found, they aren't set.
>> 2 - Have them fall through until we run out of rules or they are filled,
>> like the four values above.
>> 3 - Have them fall through, but only until we have filled the other four
>> values. Once the other four values are filled we officially stop checking
>> them.
>>
>> I am partial to 1 or 3 in this case.
>>
>
> After discussion, option 3 seems sane and has gained general
> consensus. One point I brought up was, how do you tell the system
> that you do /not/ want to use an inherited test value and also don't
> want to supply a value? IOW, what if you don't want to test a
> copy-hold ratio and yet some broader rule does set a value for one of
> these tests?
>
> The answer is that a value of 0 (zero) acts the same as "don't test"
> since all possible values will pass.
>
>> The other main issue I am seeing right now is the circ mod test. In
>> particular, the current system uses the matchpoint ID for the check. As my
>> changes make it so that there is more than one matchpoint ID possibly
>> involved there are several options:
>>
>> 1 - Negate the check when there is more than one matchpoint used in the
>> final result
>> 2 - Use only the first matchpoint found for the check
>> 3 - Have it use all matchpoints that were considered for the check (were
>> valid and before we filled in our values)
>> 4 - Have it use all matchpoints that contributed to the check (were valid,
>> before we filled in our values, AND set at least one value)
>>
>> I am partial to 3 in this case, as that would allow for creating a
>> matchpoint that would be specifically for triggering that limit, without
>> changing any of the resulting rules.
>>
>
> This question has not been addressed yet. I think that without
> broader input, and in fact outside requests, we need to sit on this
> one. I understand the argument for the flexibility of 3, but these
> matchpoints and rulesets can already be very complicated, and the
> potential for SAAD is high. Consider:
>
> * matchpoint 1 (closest match) supplies all but max fine rule, and
> has a circ-mod test for "book" that limits the user to 10 items out
> * matchpoint 2 (fall-through by group) supplies the max fine rule,
> and also has a circ-mod test for "book", but sets the limit at 5 items
> out
>
> Which do we honor? And, like the question about copy-hold ratios, how
> do we say "do NOT test per-circ-mod items out at all"? There are no
> magic values here, and the benefit of flexibility IMO is outweighed by
> the complexity of getting it right from a user perspective.
>
>> Any thoughts?
>>
>
> All that said, I think this is some awesome work. Thanks, Thomas!
>
> --miker
>
>> Thomas Berezansky
>> Merrimack Valley Library Consortium
>>
>>
>> Quoting Thomas Berezansky <tsbere at mvlc.org>:
>>
>>> Theory:
>>> Make the things returned (circulate, duration_rule, recurring_fine_rule,
>>> max_fine_rule) "fall through" when set to NULL.
>>>
>>> The attached patch attempts to make this happen on the back end, but
>>> provides no front end interface changes for configuring it.
>>>
>>> IT HAS NOT BEEN TESTED, mainly because I don't want to screw with our
>>> test system right now when others may be trying to test existing
>>> functionality.
>>>
>>> It also adds in the ability to pass in one more (optional) boolean
>>> parameter to the function to return the entire list of rules used to
>>> create the final result, intended for "debug/test" front end
>>> functionality
>>> to show what rules were considered in the fall-through checking.
>>>
>>> Pros:
>>>
>>> You can override a subset of those fields with a specific rule while
>>> allowing broader rules to fill in the holes.
>>> This may result in less duplication of information across rules, making
>>> things easier to maintain.
>>> Thus, this may result in less rules in general, and thus less processing
>>> time on sorting them overall.
>>>
>>> Cons:
>>>
>>> Manually figuring out the specifics of what will happen will take more
>>> time/effort.
>>> Changing a single rule may have a greater unintended effect on other
>>> rules.
>>> Staff would need training for when to have a rule fall through and when
>>> to set it.
>>> More time to return from the DB for any rule that is "falling through" to
>>> broader rules.
>>>
>>> Examples for the following org tree:
>>>
>>> CONS
>>> -SYSA
>>> --LIBC
>>> --LIBD
>>> -SYSB
>>> --LIBE
>>> --LIBF
>>>
>>> Implementing the following "business" rules:
>>>
>>> At the CONS level:
>>> By default, everything circulates, uses DFLT_DUR duration, DFLT_RFINE
>>> recurring fine, and DFLT_MFINE max fine.
>>> Circ Modifier "book" uses the duration BOOK_DUR
>>> Reference flagged materials don't circulate
>>>
>>> At the SYSA level there are no special rules.
>>>
>>> At the SYSB level the max fine should be SYSB_MFINE.
>>>
>>> At the LIBC level the recurring fine is LIBC_RFINE
>>>
>>> At the LIBD level circ modifier "book" uses the DFLT_DUR duration instead
>>> of "BOOK_DUR"
>>>
>>> At the LIBE level reference flagged materials circulate.
>>>
>>> At the LIBF level there are no special rules.
>>>
>>> The current method would require the following circ rules to implement
>>> those business rules:
>>>
>>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>>> CONS NULL NULL TRUE DFLT_DUR DFLT_RFINE DFLT_MFINE
>>> CONS NULL TRUE FALSE DFLT_DUR DFLT_RFINE DFLT_MFINE
>>> CONS book NULL TRUE BOOK_DUR DFLT_RFINE DFLT_MFINE
>>> CONS book TRUE FALSE BOOK_DUR DFLT_RFINE DFLT_MFINE
>>> SYSB NULL NULL TRUE DFLT_DUR DFLT_RFINE SYSB_MFINE
>>> SYSB NULL TRUE FALSE DFLT_DUR DFLT_RFINE SYSB_MFINE
>>> SYSB book NULL TRUE BOOK_DUR DFLT_RFINE SYSB_MFINE
>>> SYSB book TRUE FALSE BOOK_DUR DFLT_RFINE SYSB_MFINE
>>> LIBC NULL NULL TRUE DFLT_DUR LIBC_RFINE DFLT_MFINE
>>> LIBC NULL TRUE FALSE DFLT_DUR LIBC_RFINE DFLT_MFINE
>>> LIBC book NULL TRUE BOOK_DUR LIBC_RFINE DFLT_MFINE
>>> LIBC book TRUE FALSE BOOK_DUR LIBC_RFINE DFLT_MFINE
>>> LIBD book NULL TRUE DFLT_DUR DFLT_RFINE DFLT_MFINE
>>> LIBD book TRUE FALSE DFLT_DUR DFLT_RFINE DFLT_MFINE
>>> LIBE NULL NULL TRUE DFLT_DUR DFLT_RFINE SYSB_MFINE
>>> LIBE book NULL TRUE BOOK_DUR DFLT_RFINE SYSB_MFINE
>>>
>>> 16 circ rules total.
>>>
>>> The new method would require the following circ rules to implement those
>>> business rules:
>>>
>>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>>> CONS NULL NULL TRUE DFLT_DUR DFLT_RFINE DFLT_MFINE
>>> CONS book NULL NULL BOOK_DUR NULL NULL
>>> CONS NULL TRUE FALSE NULL NULL NULL
>>> SYSB NULL NULL NULL NULL NULL SYSB_MFINE
>>> LIBC NULL NULL NULL NULL LIBC_RFINE NULL
>>> LIBD book NULL NULL DFLT_DUR NULL NULL
>>> LIBE NULL TRUE TRUE NULL NULL NULL
>>>
>>> 7 circ rules total.
>>>
>>> Starting with the above, lets assume that SYSA wants to change their
>>> recurring fine to SYSA_RFINE.
>>> LIBC's recurring fine is to be unchanged.
>>>
>>> The current method requires the following changes:
>>>
>>> ADD the following entries:
>>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>>> SYSA NULL NULL TRUE DFLT_DUR SYSA_RFINE DFLT_MFINE
>>> SYSA NULL TRUE FALSE DFLT_DUR SYSA_RFINE DFLT_MFINE
>>> SYSA book NULL TRUE BOOK_DUR SYSA_RFINE DFLT_MFINE
>>> SYSA book TRUE FALSE BOOK_DUR SYSA_RFINE DFLT_MFINE
>>>
>>> UPDATE the LIBD entries:
>>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>>> LIBD book NULL TRUE DFLT_DUR SYSA_RFINE DFLT_MFINE
>>> LIBD book TRUE FALSE DFLT_DUR SYSA_RFINE DFLT_MFINE
>>>
>>> 4 rules added, 2 changed, total is now 20 rules.
>>>
>>> The new method would require the following changes:
>>>
>>> ADD the following entry:
>>> CIRC_LIB CIRC_MOD REFERENCE CIRC? DURATION_RULE RECURRING_FINE MAX_FINE
>>> SYSA NULL NULL NULL NULL SYSA_RFINE NULL
>>>
>>> 1 rule added, 0 changed, total is now 8 rules.
>>>
>>> Thomas Berezansky
>>> Merrimack Valley Library Consortium
>>>
>>
>>
>>
>
>
>
> --
> Mike Rylander
> | VP, Research and Design
> | Equinox Software, Inc. / The Evergreen Experts
> | phone: 1-877-OPEN-ILS (673-6457)
> | email: miker at esilibrary.com
> | web: http://www.esilibrary.com
>
More information about the Open-ils-dev
mailing list