Hi Tina,
MassLNC funded the development for the custom org unit tree, so I can
give you some background on the use cases behind the development.
It essentially was created for display purposes as we didn't like the
way systems and branches were displaying in the org unit selector.
You're right, the custom org tree won't affect the way search results
are retrieved. For our use cases, we didn't need a change in the
retrieval of search results. Its only purpose was to allow us to reorder
the org units in the selector, and therefore it doesn't play into
circ/holds policies either. I'm not quite sure how it interacts with org
unit hiding depth.
We had two specific use cases we were trying to address:
- Removal of the system level in the org unit dropdown: In
Massachusetts, we have very few multi-branch libraries, so the default
display with a branch appearing under a system did not work well for us.
Users didn't understand what the difference was between the two
different selections (and there really wasn't a difference) and it added
needless clutter to the interface. For the most part, this problem was
solved by the "Org Units Do Not Inherit Visibility" global flag (added
at the same time as the custom org trees) since it allowed us to hide
the system level while keeping branches visible. However, those hidden
system-level org units do display in the staff client, and I don't think
everyone liked that, so the custom org tree provides another means of
hiding that system level in both the public and staff view.
- As Tim mentioned in his e-mail, C/W MARS has an additional level in
their org hierarchy. Consortium > Region > System > Branch. They needed
to create this additional regional level due to the way the delivery
sorting happens in our state. They wanted holds to be filled within a
region before moving on to the rest of the consortium. However, we
didn't want libraries to display in the OPAC within each region. The
custom org tree allowed C/W MARS to interfile all of their libraries
into one big alphabetical dropdown list.
- Another use I've seen of the custom org tree is, in cases where we do
have multibranch systems, we might want the main library to display
above the other branches, even if it doesn't come first alphabetically.
We can make the main library appear out of order using the custom org tree.
I hope this helps!
Kathy
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier
On 4/1/2014 3:17 PM, Tina Ji (Project Sitka) wrote:
Hi all,
We are facing the following scenario. We wonder whether the Custom Org
Unit Tree will help.
SYS1 and SYS2 do not share their collections, meaning no holds allowed
on each other. Now BRA1 from SYS1 wants to share its collection with
all branches of SYS2, which means collection of BRA1 should show up
when a search is scoped to SYS2. For some reason, it is not desired to
move BRA1 to SYS2 on the org unit tree.
We tried the Custom Org Unit Tree. We made BRA1 under SYS2, same as
the other branches in SYS2. BRA1 showed up on the OPAC as a branch in
the search location list (and the hold pickup library list). But it
seems for 'display' only. When a search is scoped to SYS2, titles, of
which only BRA1 has copies, are not returned on the result list. We
also tried to hide an org unit from the Custom Tree, but its holdings
keep showing up on the holdings grid.
I wonder anyone is using the Custom Org Unit Tree. Can you shed some
light on how it works?
Other issues on my radar includes how custom tree interacts with the
Org Unit Hiding Depth on the Library Settings Editor, and the OUs in
circ_ and hold_matrix_matchpoints. We do not use Strict OU matches.
Thank you
Tina Ji
1-888-848-9250
Trainer/Help Desk Specialist
BC Libraries Cooperative/Sitka
