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

[Michele Morgan]

Dan brings up many of the same issues that drove us to exploring this hierarchy 
setup. Permissions should work out ok for us, since they are broken out at a 
higher level in the org tree, so that is less of an issue for us, but the 
ability to set the circ policies for different departments is important.

Avoiding bogus transits altogether is a big issue in our consortium. With the 
volume of transactions that happen at our circulation desks, and the number of 
copies that actually do have to transit, having bogus transit messages popping 
up that staff need to respond to just won't work for us.

Also a big issue is the ability to search the departments in the catalog. It 
seems to make sense to be able to limit your search to a Department the same way 
you would limit your search to a Branch. Filtering using shelving locations 
means you would need to do an advanced search, which might not be obvious to 
many users.

I'd say that Jason's approach makes more sense for the problem we're trying to 
solve. I mostly like:

"Then your circ libs can equal your owning libs and everything else will just work."

Thanks for your thoughts on this,
Michele

On 6/15/2011 9:23 AM, Dan Wells wrote:
> 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.

-- 
Michele Morgan, Technical Assistant
North of Boston Library Exchange, Danvers Massachusetts
mmorgan at noblenet.org