[OPEN-ILS-DEV] "Choose a library to search" behavior in the opac

[Dan Wells]

Hello all,

While I can see some merits for both proposals, I am not sure they are really addressing the same problems.  I would advocate at this point for something along the lines of what Jason is proposing, and here's why.  We are currently running a hierarchy very similar to what Michele has, at least with respect to having a shared circ desk for multiple org units.  One major reason we use org units rather than locations is the ability to properly limit permissions.  Each "department" in our library is managed by a different person or group of people, and the ability to keep their powers limited to their own area is very valuable.  A second significant factor involves, as noted in Michele's original email, is the ability to set "department" specific circulation policies.  If the departments are org units, this is simple to do.  As far as know, there is no built in way to set circ policies based on shelving location.

To solve the transit issue, we are currently taking a very simple approach.  We have a script run periodically (every 15 minutes, I think) which aborts any bogus transits (defined by a hardcoded list unit pairs, A to B, A to C, etc.).  This does not solve the problem of getting the transit pop-up in the client, but that is really a pretty minor annoyance, and in a way sort of helpful, since it is very clear that the item is not part of the main collection and needs to be shelved differently.

I am not too aware of the intricacies of proximity settings or perhaps "lassos" (either of which, from my naive perspective, seem like they might be useful here), but if others weigh in and we eventually end up at a more concrete proposal, I would be willing to provide some support for this, at least with testing if not with implementation.

Thanks,
Dan

>>> On 6/14/2011 at 10:59 AM, Mike Rylander <mrylander at gmail.com> wrote:
> On Tue, Jun 14, 2011 at 12:46 AM, Jason Etheridge <jason at esilibrary.com> wrote:
>> On Fri, Jun 10, 2011 at 11:04 AM, Michele Morgan <mmorgan at noblenet.org> wrote:
>>> We have the following setup in our 2.0.6 test system:
>>>
>>> Our Org tree is set up as:
>>>
>>> - Consortium
>>> -- System
>>> --- Branch
>>> ---- Department
>>>
>>> In our copies, we have set the Owning Lib (asset.call_number.owning_lib) at
>>> the Department level and the Circulation Library (asset.copy.circ_lib) set
>>> at the Branch level.
>>
>> Interesting.  This is the first time I've seen such an arrangement
>> (owning library being a child of the circ library).  Usually, the
>> owning lib and the circ lib are the same, though the circ lib will
>> change for rotating and floating collections.
>>
>>> With this setup, we've been able to create circulation policies that work as
>>> we intend based on the Owning Lib (Department). Also, the copies don't
>>> transit when checked in at a workstation registered to the branch. This all
>>> works well.
>> <snip>
>>
>> I assume avoiding transits is the big motivator here?  Hrmm.  It may
>> be worthwhile to develop a setting for suppressing transits if the
>> check-in library is within a certain proximity to the item circulating
>> library.  Or a field or mapping table that says treat lib A as lib B
>> for the purpose of transits, etc.  That may be easier than re-working
>> the OPAC and associated searches.  Then your circ libs can equal your
>> owning libs and everything else will just work.
>>
> 
> I would suggest against YAOUS (yet another org unit setting) or
> equivalence mapping.
> 
> How about, instead, adding a parent field to asset.copy_location to
> allow a hierarchical setup.  Since Shelving Location
> (asset.copy_location) is already a filterable field you could then
> create a top level Shelving Location for each Department and then
> create sub-locations under those.  Then, teach search about this
> hierarchical nature and search "down" the tree when given a non-leaf
> location.
> 
> You could approximate this today by embedding the department name a
> the front of the shelving location, but that's slightly more messy,
> perhaps.