Re: [OPEN-ILS-GENERAL] Unexpected results changing Organisational Units through Staff Client in EG 2.0 alpha4

2010-11-02 Thread Ben Shum
Repke brings up a solid point about scaring off new users trying out
Evergreen with the awkwardness experienced with trying to change org
units in the current defaults of Evergreen.  I bring this up again
because the issue with changing/deleting the default org units has come
up again on the IRC, so it's not just a few isolated incidents.

While documentation might help to address some of this, I wonder if
maybe it was hasty to change how the organization units are structured
in the default shipping of Evergreen?  I think the change was helpful if
the plan was only to edit the existing structure, but it seems that
others may just want to delete things and start from scratch.

Maybe we should approach this like what has been suggested for the
default options for permission groups and advocate some sort of option
for a blank org units tree (like maybe have only 1 for Default
Consortium, which you can edit) during the installation process.

-- Ben

On 10/22/2010 04:30 PM, Repke de Vries wrote:
 Thanks Jason, Ben and Mike.

 Mike: the command-line autogen extra step solved the not picking up 
 in the staff client pages. Confusing that the wiki page you referred
 to is part valid, part much outdated 'cause instead of the cgi-bin
 scripts for example we now have the Staff Client. Well, Robert
 Soulliere and others in DIG are working on official = most up to
 date - please read this folks docs.

 Jason and Ben: this explains that you can't delete or at least not
 easily from the staff client but should rather revert to direct
 database operations - which by the way might scare off lost of
 organisations wanting to experiment with and evaluate Evergreen.

 Yours, Repke, IISH

 Op 22-okt-2010, om 21:22 heeft Jason Stephenson het volgende geschreven:

 Just as a followup, I've been working on scripts for our migration
 next year. In those scripts, I delete all of the org units and org
 unit information except for the consortium. I also update the entry
 for the consortium entry with our information and then create the
 org_units in the script. I don't use the client for this at all. It
 works rather well if you're good with SQL.

 HtH,
 Jason



-- 
Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070, ext. 113



[OPEN-ILS-GENERAL] Unexpected results changing Organisational Units through Staff Client in EG 2.0 alpha4

2010-10-22 Thread Repke de Vries
Your help appreciated: setting up our library structure by changing  
Organisational Unit Types and Organisational Units through Server  
Administration in the Staff Client, gives unexpected and incomplete  
results.


We are talking the EG 2.0 alpha4 Virtual Image and we are prototyping  
the organisational structure in anticipation of 2.0 beta and going  
live later this year.


After some changes to text labels in Organisational Unit Types,  we  
made changes to the hierarchy of Organisational Units + the Units  
themselves.
Here is a screenshot where for example you see the out-of-the-box BR1  
changed: http://screencast.com/t/fWRTdaCnxy


First of all: actually *deleting* anything not needed proved  
impossible: sometimes the Org Units admin interface turns red and  
nothing happens; sometimes deleting did seem to happen only to have  
the out-of-the-box structure return later; this is irrespective of  
having any holdings or users or workstations attached to, say: a branch.


And testing the consequences of such changes :
- all the OPAC and staff client screens persistently keep the *old*  
text labels like for example Example Branch 1 - also after stopping  
and restarting Evegreen + Apache; and of-course we started new staff  
client sessions;  here is a screenshot:  http://screencast.com/t/ 
NR9Od8oMh96
- Holding Maintenance screens show a mixed result:  changes to Unit  
Types come through, changes to the Units themselves don't come  
through:   http://screencast.com/t/XqdW9S9jr
- Exporting records picks up the new Organisation Unit Policy Code  
IISG  (instead of BR1) and uses it on the 852

- Importing records does *not* recognise this new code IISG in 852 $b
- the new MARC 001/035 + TCN =  MARC 001 feature (see Server Admin - 
Global Flags) however *does* pick up the new Policy Code defined in  
the Consortium Org Unit and uses it for issuing authority
- there seems to be a time delay ?  After a few days now for example  
the Holding Maintenance screen + pick lists *do* seem to have picked  
up more of the changes: is that in any way likely?


What are we missing ? Which other steps than Server Admin in the  
Staff Client are necessary to have changes in the Organisation Units  
fully take effect?


Thanks, Repke de Vries, IISH








Re: [OPEN-ILS-GENERAL] Unexpected results changing Organisational Units through Staff Client in EG 2.0 alpha4

2010-10-22 Thread Mike Rylander
On Fri, Oct 22, 2010 at 10:52 AM, Repke de Vries re...@xs4all.nl wrote:
 Your help appreciated: setting up our library structure by changing
 Organisational Unit Types and Organisational Units through Server
 Administration in the Staff Client, gives unexpected and incomplete
 results.

 We are talking the EG 2.0 alpha4 Virtual Image and we are prototyping the
 organisational structure in anticipation of 2.0 beta and going live later
 this year.

 After some changes to text labels in Organisational Unit Types,  we made
 changes to the hierarchy of Organisational Units + the Units themselves.
 Here is a screenshot where for example you see the out-of-the-box BR1
 changed: http://screencast.com/t/fWRTdaCnxy

 First of all: actually *deleting* anything not needed proved impossible:
 sometimes the Org Units admin interface turns red and nothing happens;
 sometimes deleting did seem to happen only to have the out-of-the-box
 structure return later; this is irrespective of having any holdings or users
 or workstations attached to, say: a branch.

 And testing the consequences of such changes :
 - all the OPAC and staff client screens persistently keep the *old* text
 labels like for example Example Branch 1 - also after stopping and
 restarting Evegreen + Apache; and of-course we started new staff client
 sessions;  here is a screenshot:  http://screencast.com/t/NR9Od8oMh96
 - Holding Maintenance screens show a mixed result:  changes to Unit Types
 come through, changes to the Units themselves don't come through:
 http://screencast.com/t/XqdW9S9jr
 - Exporting records picks up the new Organisation Unit Policy Code IISG
  (instead of BR1) and uses it on the 852
 - Importing records does *not* recognise this new code IISG in 852 $b
 - the new MARC 001/035 + TCN =  MARC 001 feature (see Server Admin -Global
 Flags) however *does* pick up the new Policy Code defined in the Consortium
 Org Unit and uses it for issuing authority
 - there seems to be a time delay ?  After a few days now for example the
 Holding Maintenance screen + pick lists *do* seem to have picked up more of
 the changes: is that in any way likely?

 What are we missing ? Which other steps than Server Admin in the Staff
 Client are necessary to have changes in the Organisation Units fully take
 effect?


After editing Org Units or Org Unit Types, you must run the autogen.sh
script found in /openils/bin.  This regenerates static JavaScript
files from the data in the database.  See:
  
http://open-ils.org/dokuwiki/doku.php?id=evergreen-admin:policiess[]=autogens[]=sh#applying_the_changes

Also, after changing these structures (which is hopefully very rare in
practice) you will need to restart your staff client.  Because these
are not expected to change often, the staff client caches these
locally at startup.

After doing both of these, do you get results you expect?

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  mi...@esilibrary.com
 | web:  http://www.esilibrary.com