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 <[email protected]> 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 <[email protected]>: > >> 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: [email protected] | web: http://www.esilibrary.com
