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