We should also think about the ways in wich items can be selected to be part of the batch. Scanning bar codes is cool, but not enough. One should be able to do it using a kind of search/filter process: i.e. make a batch of items in branch X with location Y wih status Z. And name the batch? I agree with atz that it might be cool to be able to store the batch. Nicolas On Thu, Jul 24, 2008 at 6:05 PM, Nicole Engard <nicole.engard@liblime.com> wrote:

Paul, this is an awesome suggestion, I have had librarians at larger libraries ask about this!!

---

Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com AIM/Y!/Skype: nengard

http://liblime.com http://blogs.liblime.com/open-sesame/

On Thu, Jul 24, 2008 at 11:01 AM, Joe Atzberger <ohiocore@gmail.com> wrote:

...

Any chance of preserving the list of barcodes somehow in a way that might be used again, or by other features? This kind of batch/bulk management is going to be increasingly important as more large institutions come online.

--Joe

On Thu, Jul 24, 2008 at 9:21 AM, Paul POULAIN <paul.poulain@free.fr> wrote:

...

(http://wiki.koha.org/doku.php?id=en:development:rfcs3.2:item_statuses_bulk_c...)

We will add a page to bulk change the status or location of an item. The page will let you :

* choose the kind of info to change * the value to set

Then, the librarian with scan barcodes and all scanned items will have the data updated.

-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08

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

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

Paul POULAIN a écrit :

Nicolas Morin a écrit :

...

We should also think about the ways in wich items can be selected to be part of the batch. Scanning bar codes is cool, but not enough. One should be able to do it using a kind of search/filter process: i.e. make a batch of items in branch X with location Y wih status Z. And name the batch? I agree with atz that it might be cool to be able to store the batch. Nicolas

what about adding a feature to bulkchange a given virtual shelf ? That would be an already existing place to remember a batch. We could also port some feature that exist on OPAC to deal with basket/lists to staff interface. Then, have a bulkstatuschange applied on a virtual shelf.

If that's a good suggestion, would we need "simple bulk status change" (without remembering) or would we need both ("simple" and "through List" ?

MMMM... Not keen on that idea. I had rather have a table of process and link to a type of information processed. Since we consider having a process list + have some information on them for instance, managed_imports process on borrowers, process on issues. All those definitely are processes. It could also solve our problem with scheduled tasks (I'd rather have a second table for that one). process table : process id;process name; description; process type (CGI, commandline); options; data type; data id; system or always keep flag (Maybe some other tables to store options and data in, data out, depending on the way we ant to act) process_schedule table : processid; scheduled; time;regularity with an other table that would store the status of all the processes which could be sent. process_report table; processid; timestamplaunched; datefinished;status;results This may allow more portability on Windows. And would be much more in a OOP point of view, which is to my mind more scalable and sustainable. With a process Package which would allow New; Execute; Delete; Schedule; DisplayResults..... my 2 cts. -- Henri-Damien LAURENT

Joe Atzberger a écrit :

what about adding a feature to bulkchange a given virtual shelf ? That would be an already existing place to remember a batch. We could also port some feature that exist on OPAC to deal with basket/lists to staff interface. Then, have a bulkstatuschange applied on a virtual shelf.

Only if you are talking about changing biblio records. Unlike their analog analogues, Virtual Shelves don't contain items. (And shouldn't.)

--joe

I don't agree. They could/should also be able to contain items. I see no reason why you want to limit shelf element to biblios. For instance, it should be possible to create a virtualshelf of items in order to process them, like send them to "reliure", set a special status, create a command, recall them back, send them to another library. Imho, this type of things should eventually be possible via a virtualshelf, just need to be quite general on what a virtual shelf contains and display actions depending on elements type (It would just need to add a type of element to virtualshelves.) But maybe i am daydreaming. -- Henri-Damien LAURENT

Jesse Weaver a écrit :

I think the reason for this is because virtualshelves were never intended to refer to specific items, merely bibs, since they were used as simple collections for the public and staff's use. If we make something like what you want, it should probably be entirely separate.

<history mode="ON"> In fact, the 1st implementation of virtual shelves, done by Steve Tonnesen, relied on itemnumber, NOT biblionumber. That was a problem when you have a biblio without an item. That's also useless in most situations, as you do biblio groups most of the time. <history mode="OFF"> but the example hdl give us is correct : we could have virtual shelves on item for specific cases. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08