Summary: | Deleting an item removes the itemnumber from old_issues when it probably should not | ||
---|---|---|---|
Product: | Koha | Reporter: | Lucas Gass (lukeg) <lucas> |
Component: | Database | Assignee: | Lari Strand <lmstrand> |
Status: | Failed QA --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | andrew, bibliwho, blawlor, emmi.takkinen, gmcharlt, kebliss, kyle.m.hall, kyle, lisette, lmstrand |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36101 | ||
Change sponsored?: | --- | Patch complexity: | Small patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: |
Bug 32729: Drop constraint to items.itemnumber from old_issues-table
Bug 32729: Drop constraint to items.itemnumber from old_issues-table |
Description
Lucas Gass (lukeg)
2023-01-25 18:34:31 UTC
Unless there's a good reason for this data loss, the itemnumber should be preserved. If I've understood things correctly, resolving this issue would make it possible to calculate an accurate running total of savings based on the value of a patron's checkouts, i.e., a total that includes values for items that have been deleted. Cab Vinton/ Plaistow Public Library (In reply to Cab Vinton from comment #1) > Unless there's a good reason for this data loss, the itemnumber should be > preserved. I agree. We need this information for reports and finding out biblio details based on the itemnumber in the old_issues table etc. I propose we remove the constraint: CONSTRAINT `old_issues_ibfk_2` FOREIGN KEY (`itemnumber`) REFERENCES `items` (`itemnumber`) ON DELETE SET NULL ON UPDATE SET NULL, from old_issues-table. Same goes for old_reserves-table (propably should make a new ticket?): CONSTRAINT `old_reserves_ibfk_3` FOREIGN KEY (`itemnumber`) REFERENCES `items` (`itemnumber`) ON DELETE SET NULL ON UPDATE SET NULL, These tables are archive tables and I think this information should be preserved. I can't justify the data loss with any good reason. Created another ticket for the same issue for old_reserves: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36101 Created attachment 163019 [details] [review] Bug 32729: Drop constraint to items.itemnumber from old_issues-table This patch removes the constraint from old_issues table to the items table so a deleted item's itemnumber will be preserved in the old issues table. To test: 1. Apply patch 2. run updatedatabase.pl 3. Check constraint old_issues_ibfk_2 has been dropped Created attachment 163939 [details] [review] Bug 32729: Drop constraint to items.itemnumber from old_issues-table Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> Test notes: updatedatabase DEV atomic update /kohadevbox/koha/installer/data/mysql/atomicupdate/bug_32729.pl [14:30:50]: Bug 32729 - Drop constraint to items.itemnumber from old_issues-table Dropped constraint old_issues_ibfk_2 from old_issues Checked items out and back in, deleted items and ran report to confirm that the itemnumber is retained. I'm wondering if we should add an deleted_itemnumber column ala Bug 22421 as an alternative. Failing QA. I think my suggestion from comment 7 is the way to go since we've already established the pattern in Koha. (In reply to Kyle M Hall from comment #8) > Failing QA. I think my suggestion from comment 7 is the way to go since > we've already established the pattern in Koha. We have the same in aqorders now, so I think we can call it a pattern now. This case might still be a little different, as issues and old_issues I believe need to have the same structure/columns in order to work correctly. But... having deleted_itemnumber in issues might also be a good thing? |