[OPEN-ILS-GENERAL] Library Hierarchy Setup

[Raymond Norton]

Thank you... That is exactly the problem I was having. I was able to 
make the changes via the web interface. Everything seems to be working 
fine, but when I run autogen.sh now. I get the following error:

Updating OrgTree HTML
Can't call method "depth" on an undefined value at 
org_tree_html_options.pl line 56.

What doc did you find the info you posted in your reply?

Thanks again.





On 6/15/2010 10:40 PM, Jason Etheridge wrote:
> On Tue, Jun 15, 2010 at 3:38 PM, Raymond Norton<admin at lctn.org>  wrote:
>    
>> I am ready to customize my new server for our environment. I have read the
>> docs a bit on this and currently have the lib-setup.cgi page up. I'm not
>> clear what I can get rid of and change without causing unintended
>> consequences.
>>      
> The main gotcha is that Evergreen won't let you delete anything that
> is in use, so if, for example, you've already registered a workstation
> with the sample BR1 branch, you'd have to delete that data from within
> the database before you could delete the BR1 branch itself.  Ditto
> with users and copies.
>
> I realize now that there's another gotcha here, in that the preferred
> UI's for managing these things are located in the staff client, which
> requires you to register a location (and thus use a branch). :-)
>
> So you'd want to load these interfaces within Firefox instead of the
> local staff client application:
> https://hostname/conify/en-US/global/actor/org_unit_type.html
> https://hostname/conify/en-US/global/actor/org_unit.html
>
> These will still require authentication, but don't require a
> registered workstation.
>
> Assuming you are able to delete and modify the sample hierarchy, just
> about anything is fair game, as long as the org unit types and org
> units match up depth-wise, and you're using some org unit type that
> allows volumes and users.  Org hierarchies deeper than 4 levels are
> not common, though, and you may run into cosmetic bugs if you push it.
>
>    
>> We have a very simple k12, single location environment and will not be
>> adding new systems or branches. What changes from the example setup would be
>> recommended for a simple setup like ours?
>>      
> In your case, you could get away with just a single org unit.  Delete
> all org units but Consortium, and rename Consortium to the name of
> your library.  Modify the org unit type for Consortium so that Can
> Have Volumes and Copies is checked and Can Have Users is checked.  You
> could leave the other org unit types in place.
>
> The UI is geared for multiple libraries though, so you'll have library
> selector drop-down menus that you won't need, etc.
>
> If there's any chance at all that you might want to add other branches
> later (even if they're just functional department divisions within a
> single building, or a bookmobile, etc), I'd suggest you go with at
> least a System->Branch hierarchy.  It'd save you pain later.
>
>