[Bug 28520] New: Cancelling a hold that is in transit hides item's transit status
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Bug ID: 28520 Summary: Cancelling a hold that is in transit hides item's transit status Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: joonas.kylmala@helsinki.fi QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, martin.renvoize@ptfs-europe.com, nugged@gmail.com, stalkernoid@gmail.com When you cancel a hold that is in transfer to another branch the transfer status disappears from the item info. In the database you can see following transfers created for the items after the cancellation:
mysql> select * from branchtransfers\G *************************** 1. row *************************** branchtransfer_id: 1 itemnumber: 549 daterequested: 2021-06-07 08:11:05 datesent: 2021-06-07 08:11:05 frombranch: MPL datearrived: NULL datecancelled: 2021-06-07 08:13:22 tobranch: CPL comments: NULL reason: Reserve cancellation_reason: CancelReserve *************************** 2. row *************************** branchtransfer_id: 2 itemnumber: 549 daterequested: 2021-06-07 08:13:22 datesent: NULL frombranch: MPL datearrived: NULL datecancelled: NULL tobranch: MPL comments: NULL reason: TransferCancellation cancellation_reason: NULL
The code in koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt and catalogue/detail.pl checks whether $transfertwhen is defined but since this new code seems to create a transfer *request* there is not yet a datesent/transfertwhen created and so the transfer is not displayed. Bumbing priority to critical because this leads to librarians think availability of an item is different than what in reality it is and could cause miscommunication between the library and patrons. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_21_05_candidate -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #1 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 121686 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121686&action=edit Bug 28520: Update detail to display cancelled in transit transfers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |22160 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22160 [Bug 22160] OMNIBUS: Transfers enhancements -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #2 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121689 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121689&action=edit Bug 28520: Don't allow simply cancelling a transfer If we just cancel a transfer it will be in a state where we don't know where it originated from / was last seen. Let's treat cancelled transfers also as they would be in transit. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #3 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121690 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121690&action=edit Bug 28520: Allow creating a new transit request for item with cancelled transfer Setting $validTransfer=1 will allow us to trigger automatically a new transfer at check-in time. With this patch applied it is possible to return back home an item with cancelled hold that is in-transit. This is a fix to the regression caused by bug 26078. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #4 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121691 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121691&action=edit Bug 28520: Don't create a new transfer for a lost item We need to pass 'replace' to cancel() method, otherwise a new transfer (request) is automatically generated back to the original sending branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121689|0 |1 is obsolete| | Attachment #121690|0 |1 is obsolete| | Attachment #121691|0 |1 is obsolete| | --- Comment #5 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121693 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121693&action=edit Bug 28520: Create cancelled hold's transfer back after previous transfer finishes This fixes regression caused by "Bug 12362: Cancel transfer with hold cancelation" where cancelled hold's transfer didn't show up in intranet and opac because it create a new transfer that was not yet put in in-transit state. The original idea of bug 12362 was to be able to trigger transfer back home if a hold was cancelled. We can do it more simply by setting the $validTransfer variable true in the item check-in code when we are dealing with Reserve transfers. To test: 1) Apply patch 1) Have biblio with item in branch A 2) Create a new hold with a pickup library to branch B 3) Check-in the item at branch A and confirm the hold and transfer 4) Cancel the hold 5) Check-in the hold at branch B and notice it prompt to return it to branch A -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #6 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Wont this also prompt for return when the reserve hasn't been cancelled? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #7 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Ah, I see.. we check for resfound later.. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #8 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- (In reply to Martin Renvoize from comment #6)
Wont this also prompt for return when the reserve hasn't been cancelled?
No. I was supposed to write a better commit message but it got late, and working on it now as I got my koha-testing-docker working. Please grep the validTransfer variable and you see later it checks that it doesn't have a hold found. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #9 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- But.. this will follow 'ReturnToHome/ReturnToHolding' rather than 'Reverse' the original transfer.. I suppose that doesn't really matter. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121686|0 |1 is obsolete| | Attachment #121693|0 |1 is obsolete| | --- Comment #10 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121708 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121708&action=edit Bug 28520: Revert "Bug 12362: (QA follow-up) Fix ModItemTransfer cancellation handling" This reverts commit fbba09f63f200d3e57a8612554984d807867cf84. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #11 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121709 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121709&action=edit Bug 28520: Revert "Bug 12362: Cancel transfer with hold cancelation" This reverts commit 6c105829144cd341a4bc65ad8d0ee1f996b423d4. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #12 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121710 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121710&action=edit Bug 28520: Revert "Bug 12362: Reverse transfer upon cancellation" This reverts commit d0407686eb070c5bdf0302147a198027abea5ac0. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #13 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121711 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121711&action=edit Bug 28520: Bring back TransferCancellation reason handling from reverted Bug 12362 The code from Bug 12362 was reverted but there might be still in database transfers with the reason 'TransferCancellation' so we need to restore the code to handle displaying that information. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #14 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121712 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121712&action=edit Bug 28520: Allow creating a transfer back automatically if a hold is canceled during transit This fixes regression caused by "Bug 12362: Cancel transfer with hold cancelation" where cancelled hold's transfer didn't show up in intranet and opac because it create a new transfer that was not yet put in in-transit state. The original idea of bug 12362 was to be able to trigger transfer back home if a hold was cancelled (a regression caused by bug 26078). However, we can do it more simply by setting the $validTransfer variable true in the item check-in code when we are dealing with Reserve transfers. More down in the AddReturn() code there is also a check "and !$resfound" to make sure we only try to trigger the transfer back home automatically if there is no hold waiting at the current location the item arrived in. It should be noted however that now we only display generic message for the automatic transfer reason. Bug 12362 made the return display as the reason "Transfer was cancelled whilst in transit". However, since this fixes the original regressions caused by bug 26078 and restores similar behaviour to that I think giving a more descriptive message for example regarding a hold being cancelled can be considered a further enhancement. To test: 1) Apply patch 1) Have biblio with item in branch A 2) Create a new hold with a pickup library to branch B 3) Check-in the item at branch A and confirm the hold and transfer 4) Cancel the hold 5) Check-in the hold at branch B and notice it prompt to return it to branch A -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |12362 See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=26078 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12362 [Bug 12362] Branch transfer records orphaned on cancelled holds -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #15 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- (In reply to Martin Renvoize from comment #9)
But.. this will follow 'ReturnToHome/ReturnToHolding' rather than 'Reverse' the original transfer.. I suppose that doesn't really matter.
That was actually the original behaviour before bug 26078 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |28382 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28382 [Bug 28382] 'Reserve' should be passed through as transfer reason appropriately in branchtransfers -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #16 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Adding 28382 as a dependency, else we won't catch the case where the transfer was actioned by branchtransfers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |28527 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28527 [Bug 28527] Transfers that are cancelled whilst in transit should still appear as 'in transit' until they are received -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|22160 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22160 [Bug 22160] OMNIBUS: Transfers enhancements -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121708|0 |1 is obsolete| | --- Comment #17 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 121718 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121718&action=edit Bug 28520: Revert "Bug 12362: (QA follow-up) Fix ModItemTransfer cancellation handling" This reverts commit fbba09f63f200d3e57a8612554984d807867cf84. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121709|0 |1 is obsolete| | --- Comment #18 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 121719 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121719&action=edit Bug 28520: Revert "Bug 12362: Cancel transfer with hold cancelation" This reverts commit 6c105829144cd341a4bc65ad8d0ee1f996b423d4. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121710|0 |1 is obsolete| | --- Comment #19 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 121720 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121720&action=edit Bug 28520: Revert "Bug 12362: Reverse transfer upon cancellation" This reverts commit d0407686eb070c5bdf0302147a198027abea5ac0. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121711|0 |1 is obsolete| | --- Comment #20 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 121721 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121721&action=edit Bug 28520: Bring back TransferCancellation reason handling from reverted Bug 12362 The code from Bug 12362 was reverted but there might be still in database transfers with the reason 'TransferCancellation' so we need to restore the code to handle displaying that information. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121712|0 |1 is obsolete| | --- Comment #21 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Created attachment 121722 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121722&action=edit Bug 28520: Allow creating a transfer back automatically if a hold is canceled during transit This fixes regression caused by "Bug 12362: Cancel transfer with hold cancelation" where cancelled hold's transfer didn't show up in intranet and opac because it create a new transfer that was not yet put in in-transit state. The original idea of bug 12362 was to be able to trigger transfer back home if a hold was cancelled (a regression caused by bug 26078). However, we can do it more simply by setting the $validTransfer variable true in the item check-in code when we are dealing with Reserve transfers. More down in the AddReturn() code there is also a check "and !$resfound" to make sure we only try to trigger the transfer back home automatically if there is no hold waiting at the current location the item arrived in. It should be noted however that now we only display generic message for the automatic transfer reason. Bug 12362 made the return display as the reason "Transfer was cancelled whilst in transit". However, since this fixes the original regressions caused by bug 26078 and restores similar behaviour to that I think giving a more descriptive message for example regarding a hold being cancelled can be considered a further enhancement. To test: 1) Apply patch 1) Have biblio with item in branch A 2) Create a new hold with a pickup library to branch B 3) Check-in the item at branch A and confirm the hold and transfer 4) Cancel the hold 5) Check-in the hold at branch B and notice it prompt to return it to branch A Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #22 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- This resolves the problem as advertised, but it limited to special casing Hold Cancellations.. in the subsequent bug I propose we update the handling to generically resolve this for other cancelled transfers. Signing off -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |joonas.kylmala@helsinki.fi |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121718|0 |1 is obsolete| | --- Comment #23 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 121843 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121843&action=edit Bug 28520: Revert "Bug 12362: (QA follow-up) Fix ModItemTransfer cancellation handling" This reverts commit fbba09f63f200d3e57a8612554984d807867cf84. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121719|0 |1 is obsolete| | --- Comment #24 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 121844 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121844&action=edit Bug 28520: Revert "Bug 12362: Cancel transfer with hold cancelation" This reverts commit 6c105829144cd341a4bc65ad8d0ee1f996b423d4. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121720|0 |1 is obsolete| | --- Comment #25 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 121845 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121845&action=edit Bug 28520: Revert "Bug 12362: Reverse transfer upon cancellation" This reverts commit d0407686eb070c5bdf0302147a198027abea5ac0. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121721|0 |1 is obsolete| | --- Comment #26 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 121846 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121846&action=edit Bug 28520: Bring back TransferCancellation reason handling from reverted Bug 12362 The code from Bug 12362 was reverted but there might be still in database transfers with the reason 'TransferCancellation' so we need to restore the code to handle displaying that information. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121722|0 |1 is obsolete| | --- Comment #27 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 121847 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121847&action=edit Bug 28520: Allow creating a transfer back automatically if a hold is canceled during transit This fixes regression caused by "Bug 12362: Cancel transfer with hold cancelation" where cancelled hold's transfer didn't show up in intranet and opac because it create a new transfer that was not yet put in in-transit state. The original idea of bug 12362 was to be able to trigger transfer back home if a hold was cancelled (a regression caused by bug 26078). However, we can do it more simply by setting the $validTransfer variable true in the item check-in code when we are dealing with Reserve transfers. More down in the AddReturn() code there is also a check "and !$resfound" to make sure we only try to trigger the transfer back home automatically if there is no hold waiting at the current location the item arrived in. It should be noted however that now we only display generic message for the automatic transfer reason. Bug 12362 made the return display as the reason "Transfer was cancelled whilst in transit". However, since this fixes the original regressions caused by bug 26078 and restores similar behaviour to that I think giving a more descriptive message for example regarding a hold being cancelled can be considered a further enhancement. To test: 1) Apply patch 1) Have biblio with item in branch A 2) Create a new hold with a pickup library to branch B 3) Check-in the item at branch A and confirm the hold and transfer 4) Cancel the hold 5) Check-in the hold at branch B and notice it prompt to return it to branch A Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart+koha@gmail. | |com Status|Passed QA |Patch doesn't apply --- Comment #28 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- This patchset conflicts with bug 24434, I cannot apply both of them. Can you add a dependency and fix the conflict please? (adding the same comment there) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121843|0 |1 is obsolete| | Attachment #121844|0 |1 is obsolete| | Attachment #121845|0 |1 is obsolete| | Attachment #121846|0 |1 is obsolete| | Attachment #121847|0 |1 is obsolete| | --- Comment #29 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121951 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121951&action=edit Bug 28520: Revert "Bug 12362: (QA follow-up) Fix ModItemTransfer cancellation handling" This reverts commit fbba09f63f200d3e57a8612554984d807867cf84. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #30 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121952 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121952&action=edit Bug 28520: Revert "Bug 12362: Cancel transfer with hold cancelation" This reverts commit 6c105829144cd341a4bc65ad8d0ee1f996b423d4. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Rebased-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #31 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121953 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121953&action=edit Bug 28520: Revert "Bug 12362: Reverse transfer upon cancellation" This reverts commit d0407686eb070c5bdf0302147a198027abea5ac0. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #32 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121954 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121954&action=edit Bug 28520: Bring back TransferCancellation reason handling from reverted Bug 12362 The code from Bug 12362 was reverted but there might be still in database transfers with the reason 'TransferCancellation' so we need to restore the code to handle displaying that information. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #33 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121955 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121955&action=edit Bug 28520: Allow creating a transfer back automatically if a hold is canceled during transit This fixes regression caused by "Bug 12362: Cancel transfer with hold cancelation" where cancelled hold's transfer didn't show up in intranet and opac because it create a new transfer that was not yet put in in-transit state. The original idea of bug 12362 was to be able to trigger transfer back home if a hold was cancelled (a regression caused by bug 26078). However, we can do it more simply by setting the $validTransfer variable true in the item check-in code when we are dealing with Reserve transfers. More down in the AddReturn() code there is also a check "and !$resfound" to make sure we only try to trigger the transfer back home automatically if there is no hold waiting at the current location the item arrived in. It should be noted however that now we only display generic message for the automatic transfer reason. Bug 12362 made the return display as the reason "Transfer was cancelled whilst in transit". However, since this fixes the original regressions caused by bug 26078 and restores similar behaviour to that I think giving a more descriptive message for example regarding a hold being cancelled can be considered a further enhancement. To test: 1) Apply patch 1) Have biblio with item in branch A 2) Create a new hold with a pickup library to branch B 3) Check-in the item at branch A and confirm the hold and transfer 4) Cancel the hold 5) Check-in the hold at branch B and notice it prompt to return it to branch A Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Joonas Kylmälä <joonas.kylmala@helsinki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA Depends on| |24434 --- Comment #34 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Ok, rebased on top of bug 24434. Though, let's remove the dependency after pushing because it is not one. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24434 [Bug 24434] C4::Circulation::updateWrongTransfer is never called but should be -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #35 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- # Failed test 'No tests run for subtest "from_library relation tests"' # at /kohadevbox/koha/t/db_dependent/Koha/Item/Transfer.t line 75. The method Koha::Item::Transfer->from_library is not covered by tests! Looks like there are remaining tests. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #36 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Jonathan Druart from comment #35)
# Failed test 'No tests run for subtest "from_library relation tests"' # at /kohadevbox/koha/t/db_dependent/Koha/Item/Transfer.t line 75. The method Koha::Item::Transfer->from_library is not covered by tests!
Looks like there are remaining tests.
Shouldn't we actually keep the sub instead of removing the tests? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #37 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- Created attachment 121985 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=121985&action=edit Bug 28520: Remove tests for removed from_library function The function was unused and removed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #38 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- (In reply to Jonathan Druart from comment #36)
(In reply to Jonathan Druart from comment #35)
# Failed test 'No tests run for subtest "from_library relation tests"' # at /kohadevbox/koha/t/db_dependent/Koha/Item/Transfer.t line 75. The method Koha::Item::Transfer->from_library is not covered by tests!
Looks like there are remaining tests.
Shouldn't we actually keep the sub instead of removing the tests?
Nobody is using the code so why keep it around? Creates more work if something needs to be changed that affects this unused code. Attached patch to remove the test. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #39 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Ack.. that's a pet hate of mine.. that we don't pass through existing relationships so you have to create them each time if you want to use them (and add tests too). In this case, I do wonder about removing them.. remember, methods can be used by notices too.. so the 'from_library' may well have been helpful for peoples notice templates so personally I'd have kept it. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #40 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- (In reply to Martin Renvoize from comment #39)
In this case, I do wonder about removing them.. remember, methods can be used by notices too.. so the 'from_library' may well have been helpful for peoples notice templates so personally I'd have kept it.
That sounds bad, I think we should be explicit about the methods allowed to be used in the TT notice templates. And we remove all the time object methods... I'd still remove it and maybe we can open a new feature request for defining some stable methods for TT notices? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #41 from Joonas Kylmälä <joonas.kylmala@helsinki.fi> --- (In reply to Joonas Kylmälä from comment #40)
(In reply to Martin Renvoize from comment #39)
In this case, I do wonder about removing them.. remember, methods can be used by notices too.. so the 'from_library' may well have been helpful for peoples notice templates so personally I'd have kept it.
That sounds bad, I think we should be explicit about the methods allowed to be used in the TT notice templates. And we remove all the time object methods... I'd still remove it and maybe we can open a new feature request for defining some stable methods for TT notices?
Martin, though, up to you, if you wanna restore it now please feel free to submit patch. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #121953|0 |1 is obsolete| | Attachment #121954|0 |1 is obsolete| | Attachment #121955|0 |1 is obsolete| | Attachment #121985|0 |1 is obsolete| | --- Comment #42 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 122005 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=122005&action=edit Bug 28520: Revert "Bug 12362: Reverse transfer upon cancellation" This reverts commit d0407686eb070c5bdf0302147a198027abea5ac0. This commit was part of a series adding adding reverse transfers, i.e. transfers that were created for transfers that were cancelled and we wanted the item to return back to its sending library. This however hid the information about transfer happening and we need another approach to the problem. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #43 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 122006 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=122006&action=edit Bug 28520: Bring back TransferCancellation reason handling from reverted Bug 12362 The code from Bug 12362 was reverted but there might be still in database transfers with the reason 'TransferCancellation' so we need to restore the code to handle displaying that information. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #44 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 122007 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=122007&action=edit Bug 28520: Allow creating a transfer back automatically if a hold is canceled during transit This fixes regression caused by "Bug 12362: Cancel transfer with hold cancelation" where cancelled hold's transfer didn't show up in intranet and opac because it create a new transfer that was not yet put in in-transit state. The original idea of bug 12362 was to be able to trigger transfer back home if a hold was cancelled (a regression caused by bug 26078). However, we can do it more simply by setting the $validTransfer variable true in the item check-in code when we are dealing with Reserve transfers. More down in the AddReturn() code there is also a check "and !$resfound" to make sure we only try to trigger the transfer back home automatically if there is no hold waiting at the current location the item arrived in. It should be noted however that now we only display generic message for the automatic transfer reason. Bug 12362 made the return display as the reason "Transfer was cancelled whilst in transit". However, since this fixes the original regressions caused by bug 26078 and restores similar behaviour to that I think giving a more descriptive message for example regarding a hold being cancelled can be considered a further enhancement. To test: 1) Apply patch 1) Have biblio with item in branch A 2) Create a new hold with a pickup library to branch B 3) Check-in the item at branch A and confirm the hold and transfer 4) Cancel the hold 5) Check-in the hold at branch B and notice it prompt to return it to branch A Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Passed QA --- Comment #45 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- I've decided to restore the sub from the patch (patch amended). It makes sense to have from_library if we have to_library. Even if not used yet we are certainly going to need it soon. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |21.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 --- Comment #46 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Pushed to master for 21.11, thanks to everybody involved! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Pushed to stable CC| |kyle@bywatersolutions.com Version(s)|21.11.00 |21.11.00,21.05.01 released in| | --- Comment #47 from Kyle M Hall <kyle@bywatersolutions.com> --- Pushed to 21.05.x for 21.05.01 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_21_05_candidate | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Bug 28520 depends on bug 28382, which changed state. Bug 28382 Summary: 'Reserve' should be passed through as transfer reason appropriately in branchtransfers https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28382 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28520 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|Pushed to stable |RESOLVED CC| |fridolin.somers@biblibre.co | |m --- Comment #48 from Fridolin Somers <fridolin.somers@biblibre.com> --- Depends on Bug 12362 not in 20.11.x -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org