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

[Thomas Berezansky]

Going down your replies...

For relative OU matching:
I was planning on allow both absolute and relative matching in the  
same matchpoint, but not on the same *field*. That is, each "ou" field  
in the matchpoint would be allowed to be null, a specific OU, or a  
relative OU.

Thus, you could say that the user's home library is SYS1 OR the user's  
home library is the item circ library, and that wouldn't affect your  
ability to choose absolute or relative for the item's circ library  
field in the same matchpoint.

For Stalling Start:
I was thinking that a solution there would be if you re-froze the hold  
for longer than the stalling period then the stalling period would be  
reset on thaw.

For Age Protection:
I don't want to tear out the existing age protection checks from the  
INDB functions. I do want to be able to override them, say to do age  
protection entirely with matchpoint rules. Thus I want to add a  
boolean to the matchpoint that says "if this is true then skip the age  
protection checking block so that we don't say this is age protected".  
Matching on the age protect rule then gives the benefit of being able  
to reproduce age protection with the custom codes and more granular  
checks than just the transit range and age.

For subparts:
For my current view of implementation I am planning on using a second  
mapping table for the subparts already which would basically map the  
parts table to itself in a many to many relationship. I apologize if I  
implied that I would be creating an entirely new kind of "part" there.


Thomas Berezansky
Merrimack Valley Library Consortium


Quoting Mike Rylander <mrylander at gmail.com>:

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