[OPEN-ILS-DEV] Circ policy discussion

[Mike Rylander]

On Fri, Nov 12, 2010 at 2:51 PM, James Fournie
<jfournie at sitka.bclibraries.ca> wrote:
> Hi everyone,
>
> In the past few developer meetings there's been some vague discussion
> of the future of circ policies and script fallbacks.  I'd like to get
> the ball rolling a bit, but I'm not sure how, so I thought I'd share
> our background and some thoughts from SITKA.
>
> SITKA was one of the early adopters of Evergreen, I think we were the
> 2nd public consortia outside of Georgia, and we have all kinds of fun
> challenges that come with that, such as legacy data -- in loading our
> data onto a 2.0 server I'm encountering cruft left over from the 1.2
> days.  We have been using the legacy circ scripts from the start when
> it was the only option, and I find them extremely amazing and
> powerful, they are a wonderful invention.  Over time and with the help
> of ESI our scripts have developed into a nice little system, although
> they're not without their legacy cruft, we are able to define a unique
> JavaScript object for each library which controls all of their circ
> policy.  I have published our scripts to our sitka github page
> (http://github.com/sitka) if anyone wants to peruse them.  However,
> keep in mind SITKA is probably the most diverse consorita using
> Evergreen -- we have little shared policy and all of our sites has
> their own circulation policies.  I am pretty sure that all of our
> policy needs will be covered by the indb code in 2.0, if not,
> definitely by tsbere's patch.
>

That is very heartening news, James!  BTW, are you referring to the
fallthrough patch or the field priority ordering patch, or perhaps
both?

> I think that in terms of indb circ, we are above all interested in
> giving SITKA sites the power to control their own circ destinies.
> JavaScript is simply too much of a hurdle for many sites, and it
> complicates matters because it would also require knowledge of a
> revision control system.  Many of our sites don't even have a local IT
> person, and it would be generally preferable for library staff to be
> able to change the circ policies via a GUI.  We would like to migrate
> to indb circ but it is a very large project to migrate policies for 30
> something sites.  Currently, I am working on two patches for 1.6 and
> 2.0 to help us migrate to indb circ.  The first would separate out the
> indb holds logic so that indb holds policies can be used alongside
> legacy javascripts for circ.  Additionally, I have a patch which
> allows you to turn on legacy_script_support, but then force a site to
> use indb based on their workstation and an ou setting.  This would
> allow us to first migrate holds logic (which is relatively simple),
> and then migrate circ policy site by site.
>

I like the idea of being able to turn on in-db separately for each.
Are you planning two new config file flags, one for each?

I'm less sure about the force-to-in-db, but that may just be a
terminology issue.  I image an OU setting (or ancestor setting) that
says "no, use in-db," overriding the global legacy_script_support.  Is
that about right?

> In terms of script fallback, I'd like to see any scripting option be
> easily editable by end users rather than requiring server access.
> Obviously there's lots of challenges there though.
>
> I'd like to hear some use cases for script based circ or just about
> other sites expereinces with circ policy and Evergreen and what they'd
> like to see in the future.

The original intention was to allow the chosen matchpoint, if its
tests otherwise succeed, to perform one last test.  However, since it
was never implemented, we have free reign to change it.

Consider the following proposal: The JS itself would be directly
embedded in the field, meaning direct access via the staff client.
This code would be run in an environment identical to the legacy
scripts -- it could use load_lib(), etc -- and could essentially be
populated with the contents of the main legacy circ script.  If you
had a single catchall rule built this way that always passed on in-db
tests, then you would have a mechanism that allows you to run the
legacy scripts through the in-db interface.  The only difference I
would suggest would be that the circ ruleset (duration, fine, maxfine)
in the result object should be pre-populated with the outcome of in-db
test.  Given this, you switch to in-db immediately and implement
specific rules (overriding the catch-all) until you've reimplemented
all of the required logic.  This would allow you to find any holes in
in-db (situations where the catchall is still used), and if none are
found then you've migrated gradually without pain.

Thoughts?

-- 
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