Re: a simple update-items.pl tool

[Darrell Ulm-3]

Mason James <mason.loves.sushi@...> 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,
> or uploading a text-file of barcodes, or selecting items using  
> various fields and min/max ranges etc...
>
> but yes, at the moment ill keep the 1st draft nice and simple, and  
> focus on it accepting scanned barcodes from Circ (like the  
> branchtransfer.pl tool)
>

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.





_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.nongnu.org/mailman/listinfo/koha-devel
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel

[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@...> wrote:

Mason James <mason.loves.sushi@...> 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.

_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.nongnu.org/mailman/listinfo/koha-devel

_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha.org/mailman/listinfo/koha-devel