[Koha-bugs] [Bug 35100] Items assigned to StockRotation do not advance if a reserve is triggered before the initial transfer

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35100

Marcel de Rooy <m.de.rooy at rijksmuseum.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|BLOCKED                     |Failed QA

--- Comment #23 from Marcel de Rooy <m.de.rooy at rijksmuseum.nl> ---
QA Comment:
Brave effort!
This is a hard one. Very easy to introduce new bugs here in this minefield. Not
really sure if we do not.
I would recommend squashing here. Some changes are undone in followups.

I found one problem with the WasTransfered change (this kind of changes are
especially tricky):
This test might go wrong in t/db_dependent/SIP/Transaction.t ?
    my $result = $ci_transaction->do_checkin( $library2->branchcode, undef );
    is( $ci_transaction->alert_type, '04', "Checkin of item no issued at
another branch succeeds" );
    is_deeply(
        $result,
        {
            messages => {
                'NotIssued'       => $item->barcode,
                'WasTransfered'   => $library->branchcode,
                'TransferTrigger' => 'ReturnToHome'
            }
        },
        "Messages show not issued and transferred"
    );
=> # Looks like you failed 1 test of 18.

Also noting about WasTransfered:
=> The WasTransfered key is also used in sub transferbook. This might add
confusion?

Tidy stuff. No big deal. Just noting:
 WARN   C4/RotatingCollections.pm
   WARN   tidiness
                The file is less tidy than before (bad/messy lines before: 48,
now: 51)

General observation. No offense. Patch 3 changes 300+ lines but has no test
plan.

Another minor remark:
+    elsif ( $code eq 'TransferTo' ) {
+        ;    # Handled above, along with WasTransfered
=> Above suggests an action for WasTransfered, but there is none ?


While reviewing calls of request_transfer and so, I asked myself:
[1] Should current_branchtransfers not look at filled datesent ? Is a requested
transfer really a current transfer?
[2] updateWrongTransfer should correct destination but does it actually only
fix the source of transfer ? Note that $FromLibrary is unused.

Please fix the test. No reason found to block this patch set for other reasons.
Only intuition that things might go wrong elsewhere. We should push soon to
find these cases? Since Martin is committed to work in this area, things may
improve gradually.

-- 
You are receiving this mail because:
You are watching all bug changes.