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
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel
