[Koha-devel] a simple update-items.pl tool

[Joe Atzberger]

Shelves are biblio based, with good reason.  The item may have "more" info,
but it is quite possibly *wrong* info compared to the other items on the
same biblio. In logic, the shelf listing resembles most closely the hit list
returned from a search, except that it is composed by an individual rather
than returned by Zebra.

Importantly, the shelf should be able to represent titles where NO ITEM
exists, and therefore cannot be item-based.  Other than that, though, the
workflow to add items to a list could very well accomodate barcode scanning
in single or batch form.

--Joe

On Mar 31, 2009 8:24 AM, "Darrell Ulm" <darrellulm at smfpl.org> wrote:

Mason James <mason.loves.sushi at ...> writes: > On 2009/03/27, at 12:08 PM,
Owen Leonard wrote:

tential for the tool to be enhanced > with add/mod/saving item-batches to
run status-updates on, >...
Just an idea we could look at is how about modifying private virtual shelves
to
have this ability. This could be a switch when making a staff intranet
shelf.
This gives us a list we already have, and allows us to scan in barcodes. I
have
not recently looked, but does the virtual shelf save a biblionumber or an
itemnumber. An itemnumber would be preferable as it contains more
information
since it is one to one for the biblio instead of one to many (bib to items).

This covers the whole scanning and list making. Now we just need to add a
checked option for "bulk update" or something like that which allows us to
change the options that were specified like itype and location.

So the interface could be as follows:

Item 1
Item 2
...
Item n

[previous][options]  [bulk update]

The bulk update would then open an interface below

[location drop down] [itype drop down] [lost status drop down]
[damaged status drop down]

The benefit of using a virtual shelf it that they are persistent.  If
a library puts a list of items on display, generally they need a way to
revert
to their former locations, so they would need switched back. If they are
already in a list then there is a way to do that. Items of similar itypes
and locations could be kept in a list, with a different list for itype/
location or for whatever purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20090331/03d6b6f3/attachment-0003.htm>
-------------- next part --------------
_______________________________________________
Koha-devel mailing list
Koha-devel at nongnu.org
http://lists.nongnu.org/mailman/listinfo/koha-devel