[Koha-bugs] [Bug 8991] Add a script to delete old orders

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8991

Galen Charlton <gmcharlt at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gmcharlt at gmail.com

--- Comment #9 from Galen Charlton <gmcharlt at gmail.com> ---
(In reply to comment #7)
> 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.

Libraries I'm familiar with, if they purged old orders at all (and IMO, one
should think twice about doing so anyway because of the potential value of
data-mining past acquisitions activity), would do so only in units of fiscal
years.  I.e., one might choose to delete all closed orders for the 2011 fiscal
year, but depending on how the library handles ordering and receiving at the
beginning and end of the fiscal year, that may not actually map cleanly to a
specific cutoff date for receiving.

I agree that if one is deleting from acqorders, one should also delete the
relevant baskets.

> In the hope that these considerations may stimulate further improvements and
> since it only is one new script, passing qa.

I have some reservations about the existence of what could be a pretty major
foot-gun.  For example, imagine what would happen if one's fingers slipped when
entering the date; if you blew away closed orders from the current fiscal year,
thereby throwing your fund balances out of whack, there's no recourse except to
restore from backup.

The original bug report said:

> 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
purging old orders?

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.

I suggest that the purge job should produce an output file with the complete
contents of the rows it deletes.

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.

-- 
You are receiving this mail because:
You are watching all bug changes.