After upgrading from 19.06 to latest we recognized in our deleted items report a wrong amount of deleted items for 2021. Digging onto the problem we found, that every dataset in deleteditems with an empty deleteditems.datelastborrowed field, caused a deleteditems.timestamp set to the actual date by overwriting the former content of the field. We got the former content back by importing additionally the old database so called "koha_library_old" and the follwing SQL request (2021-12-01 was the date of our upgrade) UPDATE koha_library.deleteditems, koha_library_old.deleteditems SET koha_library.deleteditems.timestamp = koha_library_old.deleteditems.timestamp WHERE koha_library.deleteditems.barcode = koha_library_old.deleteditems.barcode AND koha_library.deleteditems.timestamp LIKE '2021-12-01%';
Hi, Maybe this comes from Bug 23081. It changes value of deleteditems.issues : $DBversion = '19.12.00.080'; if( CheckVersion( $DBversion ) ) { $dbh->do( "UPDATE items set issues=0 where issues is null" ); $dbh->do( "UPDATE deleteditems set issues=0 where issues is null" ); This impact on deleteditems.timestamp is an unwanted side effect. I don't know if it is technically possible to avoid it.
It is technically possible if you include the timestamp in the update statement I think, set timestamp = timestamp or something like that. We have had the issue before... just don't remember the bug, it's been a longer while.
Wish now I had remembered this one.
A little too late to fix this update since the version in question is no longer maintained. Something to keep in mind still for new updates.