[OPEN-ILS-GENERAL] Circulation And Holds "Rewrite"

[Mike Rylander]

This shouldn't be construed as implicit endorsement of the whole plan,
but I have some initial thoughts below.  Overall, it's heading in a
good direction, IMO.

On Mon, Mar 12, 2012 at 1:20 PM, Thomas Berezansky <tsbere at mvlc.org> wrote:
> I would like to make a number of changes to circulation and holds, but have
> determined that they will interact with each other significantly code-wise.
> Thus I am planning to do them as one large project, rather than as smaller
> chunks that would be difficult to keep working with each other
> independently. Before I begin, however, I would like input on the plans I
> have so far.

[snip]

> Relative Org Units
> ~~~~~~~~~~~~~~~~~~
>
> One major limitation of the Circ and Hold matrix tables is that all org unit
> checks are done with absolute org units. In order to say, for example, "the
> user's home library is the item's circ library" you need one rule per home
> library.
>
> I want to resolve that by adding relative org unit lookups. For a given org
> unit checking column you would be able to say "I want to match based on this
> specific org unit (current behavior) or an org unit defined by the user,
> item, or for holds the requestor".
>
> My current plans are to support the following fields for the relative
> lookups:
>
> * User's home library
> * Item's circ library
> * Item's owning library
> * Requestor's home library (for holds only)
>
> I plan on putting these checks into a table to allow for some customization,
> specifically to allow for depth modification. That would allow you to check
> against, for example, the system the user's home library is in instead of
> just the specific branch.
>

Both modes (absolute and relative OUs) need to be allowed on the same
matchpoint.  That way you can say "for items owned by a branch in
system X /and/ the user's home library is the item's circ library".

> Stalling Start
> ~~~~~~~~~~~~~~
>
> Currently stalling doesn't take into account when a hold was suspended, or
> re-activated. That means that a hold can "eat up" the entire stalling period
> by being frozen.
>
> The goal here is to add a new field to holds that is reset when the hold is
> placed or re-activated. That field would then be used for stalling
> calculations, allowing for stalling periods to occur on a hold that spent
> weeks suspended.
>

Would freezing and then thawing a hold cause it to go through a new
stalling period, or does this only apply to holds that start frozen?
Or, perhaps, are frozen within the initial stalling period?

> Age Protection
> ~~~~~~~~~~~~~~
>
> Currently age protection in INDB rules is a copy level one rule check, but
> is remarkably inflexible. The addition of custom failure codes will permit a
> hold rule to pretend to be age protection, but without a couple of
> additional fields on the hold matrix that may not be enough.
>
> Thus, I want to add two more fields to the hold matrix for age protection
> purposes. The first is a match field for the age protection rule in use, to
> allow matching of copies that use specific age protection rules. This would
> allow, for example, the addition of a second age protection check on top of
> the normal one for a second range, so a rule that limits to the branch could
> then be extended to include the system for an extra period of time.
>
> The second field I want to add is a result field to allow a rule to skip the
> normal age protection checks. Set globally you would be moving age
> protection checks 100% into the hold matrix rules, but there are other use
> cases as well. For example, a special user group that gets to ignore age
> protection for some reason.
>

I'm not following this last part.

> Subparts
> ~~~~~~~~
>
> Currently a copy can have a single part assigned to them. This can be a
> problem when a patron wants, say, a single DVD from a box set, but the box
> set is broken up in multiple ways. The patron has the option of picking one
> part that covers the DVD they want and waiting for that hold to fill or
> placing one hold for each part that contains the DVD they want and possibly
> getting them all at once.
>
> This would solve that problem by creating an optional list of "Subparts" for
> each part. If set then the part would fill holds for the part itself or
> subparts thereof.
>
> For example, if you have a "Disc 1-3" part you could have subparts of "Disc
> 1", "Disc 2", "Disc 3", "Disc 1-2", and "Disc 2-3". The "Disc 1-2" part may
> be defined as having "Disc 1" and "Disc 2" as subparts, and the same for
> "Disc 2-3" with "Disc 2" and "Disc 3". A patron placing a hold on "Disc 2"
> would then be able to get a copy flagged as "Disc 2" directly, or a copy
> that is flagged as "Disc 1-3", "Disc 1-2", or "Disc 2-3" to fill their hold.
>
> A secondary checkbox, only visible when subparts are in use, could allow for
> patrons to indicate whether they want any part that can fill the request or
> only the specific part they are selecting.
>

Alternative idea: how about a part grouping map.

Using your example above, you would have (potentially unused) parts
called "Disc 1-3", "Disc 1-2", "Disc 2-3", "Disk 1", "Disk 2" and
"Disk 3". Then in a new table you record any "contains/contained-by"
relationships.  In the UI you display the distinct union of in-use
parts ("Disk 1", "Disk 3", "Disc 1-3", "Disc 1-2" and "Disc 2-3" --
note that "Disk 2" is not directly used) and all parts on the
"contained-by" side of an in-use part ("Disk 1", "Disk 2" (though not
directly used) and "Disk 3").  This is very similar to your proposal,
but the important difference is that "subparts" are not special --
they're just the fines-grained parts.  At targetting time we simply
look at the "contained-by" direction of the grouping map to find the
larger sets.  I'm not sure that there's much benefit to the
complication of allowing the user to say that they /must/ get only
"Disk 3", but that "Disc 1-3" and "Disc 2-3" are unacceptable.

-- 
Mike Rylander
 | Director of Research and Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com