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<[email protected]> wrote:
On Tue, Jun 14, 2011 at 12:46 AM, Jason Etheridge<[email protected]>
wrote:
On Fri, Jun 10, 2011 at 11:04 AM, Michele Morgan<[email protected]>
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
[email protected]
