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

[John Morris]

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.

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
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.

And worse still.  I'm now increasingly of the belief that there are
THREE possibilties when making changes to the org chart.

1.  It works
2.  Flaming death.
3.  It might work... or it might result in flaming death.

I now have a situation where the exact same sequence of commands have
the flaming death happen at a different step.  Start a fresh load of the
db.  Run that script to whack away the examples.  Now look at the org
unit types.  Delete the bottom one.  Run autogen.  Reload that page and
delete the bottom one.  Run autogen.  I have had flaming death happen
after the first delete, the second delete and made it all the way a few
times.  Normal bugs are bad, non deterministic ones are a horror.

> In version 1.4 and forward, this can (should?) be done from within the staff client (Admin -> Server Settings -> Organizational Unit Types/Organizational Units).

Perhaps, but tried that first.  Kept stepping on a different land mine.
Whichever of the example org codes the staff client gets associated to
can never be removed.  I'm guessing from a misguided attempt to avoid an
incoherent database when actor.workstation would be left with a
reference to a non-existent id.  So I dug around the wiki and found the
web interface and the advice to wipe the examples.

> We have also had problems "undoing" org_unit changes in our test environments.  They have required a bit of database work (that I have not seen documentation for).

Have tried manually probing the database, most attempts to change
anything that way just end up with autogen going into it's "I'm going to
keep dying now until you nuke the db and start over.  So Nyeh!" routine.
So is there a way to actually fix it?

And while pondering new stuff to try I have been running the upgrades to
get more current.  1.6.0.6 stopped the oddball error in the staff
client.  At 1.6.0.8 now and still no relief on the autogen death bug.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20101216/d1eb926a/attachment.pgp