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