We use custom org unit trees but solely for the purpose of display in the OPAC so that we can have a straight alphabetical list (otherwise our region information would showup). I did not think custom org trees affected holds policies or circ polices.
Tim Spindler Manager of Library Applications. C/W MARS On Tue, Apr 1, 2014 at 3:17 PM, Tina Ji (Project Sitka) < [email protected]> 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 > > > -- Tim Spindler [email protected] *P** Go Green - **Save a tree! Please don't print this e-mail unless it's really necessary.*
