https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38588
Emily Lamancusa (emlam) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |ASSIGNED Assignee|[email protected] |emily.lamancusa@montgomeryc |ity.org |ountymd.gov CC| |emily.lamancusa@montgomeryc | |ountymd.gov --- Comment #4 from Emily Lamancusa (emlam) <[email protected]> --- Looks like this was an underlying bug with the modal, which bug 35721 exposed: - AddReturn initiates a transfer and sends the corresponding message to returns.pl - returns.pl shows the modal - the Print Slip button reloads(?) returns.pl with a cud-dotransfer op, which initiates a new transfer ModItemTransfer was automatically cancelling the old transfer in the background when told to initiate a new one, but Koha::Item->request_transfer doesn't cancel the old transfer; it throws an exception instead. Not sure if this was introduced when the op parameters were modified for CSRF, or if it was present before then. Either way, it seems to be fixed just by making sure the modal sends cud-transfer instead of cud-dotransfer if a transfer has already been initiated. (Patch for that coming...just need to write a good test plan for it) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
