Summary: | Clears loan history | ||
---|---|---|---|
Product: | Koha | Reporter: | Fred <freddyguerr> |
Component: | Circulation | Assignee: | Bugs List <koha-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | Testopia <testopia> |
Severity: | critical | ||
Priority: | P5 - low | CC: | freddyguerr, gmcharlt, jonathan.druart, jschmidt, kyle.m.hall, ricvargasmed |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18003 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18242 |
||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: |
Chronology of error
Bug 18185: [SOLUTION 1]DB changes - remove PK on old_issues.issue_id Bug 18185: [SOLUTION 1]Schema changes Bug 18185: [SOLUTION 1]Remove primary key on old_issues.issue_id |
Description
Fred
2017-03-01 03:30:15 UTC
Created attachment 60749 [details]
Chronology of error
Chronology of error in image
Something in the logs? (In reply to Jonathan Druart from comment #2) > Something in the logs? In the log you do not see any errors To reproduce this error I did the following. - Provide a copy to a user - Check movement history - All loans that the user has - Return the sample - Check movement history - The user loans will be displayed, without the last one returned Note: sometimes I save the returns, but the 3 exercises reproduced the error. Tested on Koha 16.05 and 16.11 installed by packages in Debian 8 and Ubuntu 16.04 LTS Ricardo, I cannot recreate on 16.11.04 (using MariaDB). Can you confirm that you are not using MySQL in strict mode? See https://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages#Ubuntu_16.04_and_MySQL_5.7 Change from mysql to mariaDB without success, the error is maintained, I have Debian 8 mysql Ver 15.1 Distrib 10.0.29-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2 Server version: Apache/2.4.10 (Debian) Can you provide a screencast? This is the screencast. http://autode.sk/2na3tNf I think you face the same problem as bug 18003, but for issues. To confirm it, try: 1. Issue an item for a patron, note the itemnumber of this item 2. Get the issue id of this issue: SELECT issue_id FROM issues WHERE itemnumber=ITEMNUMBER; If you do not know the item number, you can get it from the barcode with: SELECT itemnumber FROM items where barcode="BARCODE"; Then check if this issue_id already exists in the old_issues table: SELECT COUNT(*) FROM old_issues WHERE issue_id=ISSUE_ID See also bug 18242. Created attachment 60966 [details] [review] Bug 18185: [SOLUTION 1]DB changes - remove PK on old_issues.issue_id Created attachment 60967 [details] [review] Bug 18185: [SOLUTION 1]Schema changes Created attachment 60968 [details] [review] Bug 18185: [SOLUTION 1]Remove primary key on old_issues.issue_id The table old_issues has a primary key defined on the issue_id column. This issue_id comes from the issues table when an item is checked in. In some case the value of issue_id already exists in the table Basically this happens when an item is returned and mysqld is restarted: The auto increment value for issues.issue_id will be reset to MAX(issue_id)+1 (which is the value of the last entry of old_issues). See also the description of bug 18003 for more informations. The easier solution seems to add a new column id as a primary key. The changes to the codebase are very small. However this will raise few problems: - We can no longer assume that accountlines.issue_id==old_issues.id (I guess it is problematic). - Code in Koha::REST::V1::_object_ownership_by_checkout_id is wrong assuming that old_issues.issuing_id is unique Can I ask what is the starting Koha version that's impacted by this bug? 16.05 or earlier? 16.11? thank you. (In reply to J Schmidt from comment #15) > Can I ask what is the starting Koha version that's impacted by this bug? > 16.05 or earlier? 16.11? thank you. This bug impacts all Koha versions, but only in very specific cases. Basically it happens if you restart the DBMS and that the last item that has been checked out is checked in. In that case the auto increment value of the issue table become lower than the max value of old_issues.issue_id After the restart, the next issue will get an issue_id that already exists in the old_issues table. When this issue will be checked in and moved to the old_issue table, the copy of the data to the old_issues table will fail and the row will be deleted from the issues table => data are lost! |