[OPEN-ILS-DEV] Re: [OPEN-ILS-GENERAL] Copies editor templates--renaming or management

Jason Etheridge jason at esilibrary.com
Wed Mar 19 00:51:02 EDT 2008


>  Are these on the to-do list (or could they be placed there, please), or
>  are they unlikely to be used by others, or have I missed an easier way
>  to accomplish my goal?

Hi Bryan,

Thanks for the suggestions!  And for pointing out the race condition
with saving templates (this should be easy to fix).

Here are some possibilities for folks to ponder (some of this might be
suitable just for the OPEN-ILS-DEV participants, but since we started
out cross-posting...):

1) Add a Rename button
-- This would be easy, and I'm just going to do it unless someone
beats me to the punch.

2) Make a management interface for seeing all templates at a glance,
and manipulating them externally (rename, export, import, delete), but
leave the internal manipulation (what attribute gets set to what) to
the Item Attribute Editor.  So this management interface could be
spawned from the item attribute editor and/or from the Local Admin
menu.
-- This doesn't address the current need for using a real/potential
item with the Item Attribute Editor or how easy it is to invoke, but
we can address that separately

3) Give the Item Attribute Editor another mode and entry point where
it's just being used for template manipulation, and not for item
manipulation.
-- There are currently multiple entry points for the Item Attribute
Editor (Holdings Maintenance, Copy Buckets, and Item Status), and you
can use it with yet-to-be-created items (Volume/Copy Editor) or with
Pre-Cataloged items (when you use a barcode during checkout that is
not in the system, you have the option of creating an item on the fly
that is just not attached to any bib record or volume), in addition to
existing items.  I think most existing Evergreen users create their
templates as they need them while they're working on real items, but
wanting to systematically configure a set of templates up front is a
legitimate desire, in my opinion.

The issue with trying to use a yet-to-be-created item to hang the Item
Attribute Editor off of (where you Add Volumes/Add Items but Cancel
instead of Create) is that you can still create volumes, which while
harmless, can be unaesthetic.  Also worth noting, is that the "Owning
Library" field presented in the Item Attribute Editor is a convenient
fiction.  The Owning Library is actually a field on the Volume, so as
you change the Owning Library, you're actually either referencing
existing volumes or creating new ones (auto-vivicating them), on the
fly.

Using a pre-cataloged barcode is a good poor man's solution for
spawning the Item Attribute Editor for template manipulation (example:
hit F5, scan in a pre-cat barcode, perhaps "madeup1", then select Edit
Item Attributes), except that the Owning Library field is disabled, so
setting a template to work with that field wouldn't be possible if
working with a pre-cat.

Another thing for us to consider is that the Shelving/Copy Locations
and the library-defined Statistical Categories (and entries) can
change based on the Owning Lib and Circ Lib for the items being
edited, so if we do create a "template-edit-ony" mode, and don't want
to necessarily include changes to Owning/Circ lib to our templates,
then we'll need a way to specify pertinent libraries on invocation of
the interface.

Fun stuff!

One other thing that I've been meaning to do, that someone else is
welcome to take a shot at.  I'm currently storing these templates for
each user as an actor::user_setting object, and make use of
open-ils.actor.patron.settings.retrieve and
open-ils.actor.patron.settings.update.  But I'm using just one key
("staff_client.copy_editor.templates") and storing a potentially huge
Javascript object as the value.  We should really break that up and
use one key per template, and perhaps a master key that stores a list
of all the templates.

It would also be nice if we could make use of org_settings in addition
to usr_settings.  Then you could define a set of templates just once
that get inherited by all staff for that org.

-- 
Jason Etheridge
 | VP, Community Support and Advocacy
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  jason at esilibrary.com
 | web:  http://www.esilibrary.com


More information about the Open-ils-dev mailing list