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 <tsb...@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: mi...@esilibrary.com | web: http://www.esilibrary.com