Stephen Hedges a écrit :
Thanks, Owen --
I haven't look at the code, but it seems like this should be easy to fix. Before deleting the itemnumber, do "SELECT * FROM issues WHERE itemnumber=? AND returndate IS NULL" and if the fetchrow following execution is undefined, then it's OK to proceed with the deletion. But I guess catching the error and showing a warning screen gets a little bit more complicated.
Stephen
On Apr 5, 2005, at 2:51 PM, Owen Leonard wrote:
Looks like this is a long-standing one:
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=472
I updated it and added my 2 cents. To get it fixed, though, we may have to catch Paul while he's here and chain him in the server room until he's taken care of it.
Digging into bugzilla & finding this mail at the same time. Stephen is right : 2 ways to fix it : * the easiest : don't delete if there is an issue & don't warn the user either (this one requires only a checking in C4/Biblio.pm before deleting the item) * the easy : set the deletion button only if there is no issues (and reserve, the problem is probably the same). this one requires some code in perl + minor modifs in template (a TMPL_IF) * the best : warn the user and ask him if he prefers the deletion with auto-return & removal of reserves, or cancel the deletion. This last requiring a new screen. PS : about the chain in the server room, remember we will be 5 from france and you are only 3 :-D I'll also get a chain-cutter with me. Oups, would be a bad idea, I could be caught as a terrorist ;-) ) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)