http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8991 --- Comment #11 from Jonathan Druart <jonathan.druart@biblibre.com> --- (In reply to comment #7) Hi Marcel and Galen,
I only wonder if you should only delete from aqorders and if receiveddate should be the date to trigger the action.
It is the request from our customer.
Why not delete baskets? Now we can be stuck with empty baskets. Would you really want to delete orders from an open basket or a basket that has not been received fully?
I will provide a new patch in order to delete empty closed baskets.
Personally, I would go for a job that deletes inactive baskets (closed and all received) with creationdate as trigger. E.g. I could annually delete all inactive baskets, created more than one year ago or something.
It could be a great improvement. (In reply to comment #9)
I agree that if one is deleting from acqorders, one should also delete the relevant baskets.
Yep, will be done.
We need a script to delete old orders To which I ask: why? Is there a specific way in which the old orders are getting in the way? Is there a regulatory requirement that's satisfied by
The original bug report said: purging old orders?
It is a need for some customers to delete old orders. I suppose it is to avoid to have too many orders. After a time, it becomes useless to keep all of them.
I'm not trying to be difficult, but I do think that sometimes it's better for this sort of maintenance to be done via SQL rather than a script. At least when you're staring at the 'mysql>' prompt, you likely know that you're about to do something potentially dangerous.
Yes but with a cronjob, it is easily to call a script rather than execute a sql query.
I suggest that the purge job should produce an output file with the complete contents of the rows it deletes.
The following patch will add a 'confirm' flag. Maybe it fixes this problem?
All of that said, ultimately, somebody who runs a script called 'purge_orders.pl' presumably will have an idea of what they're in for, so I will push this patch in a day or two, though with a follow-up to add a dry run mode. However, I would appreciate it if the original patch submitter could respond to Marcel's and my questions and comments.
I hope I answered to all of your questions. (In reply to comment #10)
Also, I question the notion of this script existing as a _cronjob_. Is the idea really to run it automatically?
I think misc/maintenance is a better home for this script.
The idea is to run the job all nights (or weeks/months/...), so yes it is a cronjob. -- You are receiving this mail because: You are watching all bug changes.