[koha-commits] main Koha release repository branch 17.05.x updated. v17.05.01-74-g5cbe7c1

[Git repo owner]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "main Koha release repository".

The branch, 17.05.x has been updated
       via  5cbe7c17d88ac4779354ce46db7981d0e8b41faf (commit)
      from  f0655d5ab91ff810298878fdc96016cdf09d6c0f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 5cbe7c17d88ac4779354ce46db7981d0e8b41faf
Author: Jonathan Druart <jonathan.druart at bugs.koha-community.org>
Date:   Thu Jul 20 13:39:43 2017 -0300

    (17.05.x) Bug 18966: Do not deal with duplicate issue_id on checkin
    
    Koha suffers of big bugs due to its history: When data are deleted, they are moved to another tables.
    For instance issues and old_issues: when a checkin is done, it is moved to the old_issues table.
    That leads to a main problem that is described on https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix
    
    However we tried first to fix the problem (for issues/old_issues) at code level on bug 18242.
    The goal was to prevent data lost.
    Data lost may happens in this case:
    Check an item out (issue_id = 1)
    Check an item in (issue_id = 1)
    Restart MySQL (reset auto increment for issue_id to 1)
    Check an item out (issue_id = 1)
    Check an item in => BOOM, the issue_id is a PK in old_issues and the move fails.
    Before bug 18242 the data were lost, we inserted the value into old_issues, which fails silently (because of RaiseError set to 0 in Koha::Database), then delete the row from issues.
    That has been fixed using a transaction.
    
    This patch introduced a regression we tried to fix on bug 18651 comment 0, the patron was charged even if the checkin was rejected.
    A good way to fix that would have been to LOCK the tables:
    1- Start a transaction
    2- LOCK the table to make sure nobody will read id and avoid race conditions
    3- Move the content from one table to the other, dealing with ids
    4- UNLOCK the table
    5- Commit the transaction
    But there were problems using LOCK and DBIx::Class (See commit 905572910b3a - Do no LOCK/UNLOCK the table).
    
    Finally the solution implemented is not acceptable for several reasons:
    - batch checkins may fail
    - issue_id will always stay out of sync (between issues and old_issues)
    See 18651 comment 66.
    
    Since the next stable releases are very soon, and we absolutely need to fix this problem, I am suggesting to:
    1- Execute the move in a transaction to avoid data lost and reject the checkin if we face IDs dup
    => It will only reject 1 checkin (max is 1 * MySQL restart), no need to deal with race conditions,
    2- Display a warning on the checkin page and link to a solution/explanation
    3- Communicate as much as we can on the proper fix: Update auto increment values when the DBMS is restarted - https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix
    4- Display a warning on the about page for corrupted data (see bug 18931)
    5- Write and make available a maintenance script to fix corrupted data (TODO LATER)
    
    Signed-off-by: Tomas Cohen Arazi <tomascohen at theke.io>
    Signed-off-by: Fridolin Somers <fridolin.somers at biblibre.com>

-----------------------------------------------------------------------

Summary of changes:
 C4/Circulation.pm                                  |   31 ++++++------------
 circ/returns.pl                                    |    3 ++
 .../intranet-tmpl/prog/en/modules/circ/returns.tt  |    5 +++
 t/db_dependent/Circulation/Returns.t               |   33 +++++++++++++-------
 4 files changed, 39 insertions(+), 33 deletions(-)


hooks/post-receive
-- 
main Koha release repository