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.
signature.asc
Description: This is a digitally signed message part
