[OPEN-ILS-GENERAL] Problems with the org chart

[Dan Scott]

Ah, using the power of reading backwards, I see that you did provide
us with some of these details in your first message. Sorry about that.

I'd still like to see the contents of your actor.org_unit and
actor.org_unit_type tables. We probably need to add some context to
the official documentation at
http://docs.evergreen-ils.org/1.6/draft/html/serveradministration.html#orgunitsandtypes

So:

Are you trying to use the existing actor.org_unit_type named "System"
(with depth = 1 and parent = 0) as the Org Unit Type for the Org Unit
at the top level of your hierarchy? If so, no dice: that means that
you'll have an Org Unit with a depth of 1 at the depth 0, and things
blow up.

My suggestion would be to change the name of the out-of-the-box Org
Unit Type named "Consortium" to "System", and to change the name of
the out-of-the-box Org Unit Type named "System" to "Branch", and blow
away the other org unit types.

Here's a SQL recipe for setting up something that seems to be what you
want using an out-of-the-box database schema (from trunk, but should
be relatively easy to adjust to 1.6):

-- Delete all but the core org unit
BEGIN;
DELETE FROM actor.org_unit WHERE id > 1;
DELETE FROM actor.org_address WHERE id > 1;
DELETE FROM actor.workstation WHERE owning_lib > 1;
COMMIT;

-- Clean up our org unit types, in preparation for creating the org
unit hierarchy we want
BEGIN;
DELETE FROM actor.org_unit_type WHERE id > 2;
UPDATE actor.org_unit_type SET name = 'System', can_have_users = TRUE
WHERE id = 1;
UPDATE actor.org_unit_type SET name = 'Branch', can_have_users = TRUE,
can_have_vols = TRUE WHERE id = 2;
COMMIT;

-- Create a branch that hangs off the only remaining parent branch
-- We'll point at the org address with ID 2, which we'll create within
this transaction
BEGIN;
INSERT INTO actor.org_unit (parent_ou, ou_type, ill_address,
holds_address, mailing_address, billing_address, shortname, name)
  VALUES (1, 2, 2, 2, 2, 2, 'MYBRANCH', 'My Branch');

-- Find out what ID was assigned to the new branch
SELECT id FROM actor.org_unit WHERE shortname = 'MYBRANCH';

-- Result is 101

-- Create our required org address, pointing back to org unit 101
INSERT INTO actor.org_address (id, org_unit, street1, city, state,
country, post_code)
  VALUES (2, 101, 'Fake Street', 'Fake', 'Fake', 'Fake', 'FOO BAR');

COMMIT;

After this, autogen.sh runs and I can register the workstation and
start adding items to the new branch; the two-level hierarchy seems to
be working fine in that limited testing. I'm doing this with a stock
install of Evergreen trunk, so you might need to adjust slightly if
columns have been added to any of the tables where I'm inserting rows
compared to your version.

Dan

On 16 December 2010 23:06, Dan Scott <dan at coffeecode.net> wrote:
> On Thu, Dec 16, 2010 at 09:25:49PM -0600, John Morris wrote:
>> On Thu, 2010-12-16 at 19:39 -0500, Sharp, Chris wrote:
>>
>> > Evergreen works this way because it was initially designed for PINES, in which this is the setup.  I'm honestly not sure what sorts of improvements have been added in the last couple of versions that might accommodate the setup you're looking for.
>>
>> Which wouldn't be a problem if a) It were known what the rules really
>> are so I'd know what I have to settle for and b) if touching things
>> weren't so fatal.  Kinda shaking my confidence in EG in general knowing
>> there are user exposed controls that must be adjusted yet are one wrong
>> mouse click from a 100% dead and unrecoverable installation.  And I
>> haven't even started importing data yet.  I know Thou Shalt Make
>> Backups, but this really kicks it up a notch.
>
> Well - they're exposed, but you can't change anything if you don't have
> the appropriate permissions (which require at least administrator
> access) - unless you're talking about the config.cgi set of tools, which
> are both heavily deprecated (even removed from 2.0) and which come with
> a warning that they should be protected from access. For the new
> age library hierarchy editing tools, I took away the required
> permissions from everybody in our consortium on the day we went live and
> one of our local administrators made their library a child of itself and
> brought the system back down for a while. Heh.
>
> So, given the readily available virtual images and the ability to
> install as many copies of Evergreen wherever you want, the idea is that
> you should be able to practice these steps and gain knowledge before you
> go into production.
>
> Yes, it's a pain point, but you set up the library hierarchy once and
> then (if anything) just tweak it after that. Which is probably why
> anyone who has got past that point hasn't done much in the way of
> documenting what they did to get past that point. It would be great for
> a whiz-bang perfect UI to drop from the heavens, too, but it's not on my
> employer's priority list (we're live and investing in things we need),
> and I suspect it's not on most library's list of things they're willing
> to pay for or have their developers work on; they want customizations or
> additional functionality that will help them every day after they go
> live. But I do think a combination of documentation and possibly tool
> tweaks would be a great investment for others interested in adopting
> Evergreen.
>
>> And it gets worse.  Ok, I'll accept a three level system, but is it
>> possible to change the name of the Consortium from CONS?  Can it be
>
> You don't need to accept a three level system - see
> http://nws.evergreencatalog.com/ for an example. And the Consortium name
> there is NWC
> (http://nws.evergreencatalog.com/opac/common/js/en-US/OrgTree.js is one
> of the files generated by autogen.sh)
>
>> done?  I got really steamed a while ago and dug into
>> Open-ILS/src/sql/Pg/950.data.seed-values.sql and tried having the system
>> just initialize a different value instead of CONS.  build-db.sh ran
>> normally and I could see the new default value in the web interface,
>> however autogen.sh blew up same as if I had changed it post install.
>
> It's too bad you waited this long to ask for help; there might be
> something else going on in your configuration that we could help sort
> out - have you told us what error message autogen.sh blows up with? Does
> it blow up with a stock install of Evergreen?
>
> Also, can you show us the contents of your actor.org_unit and
> actor.org_unit_type tables?
>