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<[email protected]> 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.
