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. -- Jason Etheridge | VP, Tactical Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com Please come by and visit the Equinox team and learn more about Evergreen, Koha, and open source options ALA Annual meeting in Washington, DC June 24-28, 2010 booth # 1303
