+++ This bug was initially created as a clone of Bug #18372 +++ When checking in an item from another library the user is prompted whether the item should go into transit if they respond "Yes, print slip" no transit is created and the item status is shown as Available. This bug appears to be a resurgence of bug 18372 since we pushed bug 24085.
Test plan * Set AutomaticItemReturn system preference is set to "Don't" * Check in an item that belongs to another library, a dialog will ask you if you want to transfer. * Click 'Yes, print slip' * Look at the item record and note the status is 'Available', it should be 'In transit to...'
Created attachment 119044 [details] [review] Bug 28064: Add dotransfer field to slip print submission By changing the code to only do a javascript triggered submission from the from button we lose the original buttons name and value elements upon submission. This patch checks for those fields in the JS capture and triggers the addition of a new hidden form field to contain the dotransfer data. Test plan 1/ Set AutomaticItemReturn system preference is set to "Don't" 2/ Check in an item that belongs to another library, a dialog will ask you if you want to transfer. 3/ Click 'Yes, print slip' 4/ Look at the item record and note the status is 'Available'. 5/ Apply patch 6/ Follow steps 2 - 4 7/ Note the status is now 'In transit to...' 8/ Signoff
Created attachment 119045 [details] [review] Bug 28064: (follow-up) Do not re-trigger transfer if it already exists For some unknown reason the 'Print slip' button for when a transfer has already been triggered also had the 'dotransfer' name attribute. It won't have been getting passed to the form on submission due to the bug with JS submissions and that this particular button was always a button and not a submit in the past. However, it does need removing to prevent the re-triggering now.
Created attachment 119055 [details] [review] Bug 28064: Add dotransfer field to slip print submission By changing the code to only do a javascript triggered submission from the from button we lose the original buttons name and value elements upon submission. This patch checks for those fields in the JS capture and triggers the addition of a new hidden form field to contain the dotransfer data. Test plan 1/ Set AutomaticItemReturn system preference is set to "Don't" 2/ Check in an item that belongs to another library, a dialog will ask you if you want to transfer. 3/ Click 'Yes, print slip' 4/ Look at the item record and note the status is 'Available'. 5/ Apply patch 6/ Follow steps 2 - 4 7/ Note the status is now 'In transit to...' 8/ Signoff Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Created attachment 119056 [details] [review] Bug 28064: (follow-up) Do not re-trigger transfer if it already exists For some unknown reason the 'Print slip' button for when a transfer has already been triggered also had the 'dotransfer' name attribute. It won't have been getting passed to the form on submission due to the bug with JS submissions and that this particular button was always a button and not a submit in the past. However, it does need removing to prevent the re-triggering now. Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Works as described.
Created attachment 119440 [details] [review] Bug 28064: Add dotransfer field to slip print submission By changing the code to only do a javascript triggered submission from the from button we lose the original buttons name and value elements upon submission. This patch checks for those fields in the JS capture and triggers the addition of a new hidden form field to contain the dotransfer data. Test plan 1/ Set AutomaticItemReturn system preference is set to "Don't" 2/ Check in an item that belongs to another library, a dialog will ask you if you want to transfer. 3/ Click 'Yes, print slip' 4/ Look at the item record and note the status is 'Available'. 5/ Apply patch 6/ Follow steps 2 - 4 7/ Note the status is now 'In transit to...' 8/ Signoff Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Created attachment 119441 [details] [review] Bug 28064: (follow-up) Do not re-trigger transfer if it already exists For some unknown reason the 'Print slip' button for when a transfer has already been triggered also had the 'dotransfer' name attribute. It won't have been getting passed to the form on submission due to the bug with JS submissions and that this particular button was always a button and not a submit in the past. However, it does need removing to prevent the re-triggering now. Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Here is another signoff in the hope of helping.
Hum, actually I don't know how to test the second patch. «However, it does need removing to prevent the re-triggering now.» Didn't found how to do a re-triggering when not having the second patch.
Created attachment 119585 [details] [review] Bug 28064: Add dotransfer field to slip print submission By changing the code to only do a javascript triggered submission from the from button we lose the original buttons name and value elements upon submission. This patch checks for those fields in the JS capture and triggers the addition of a new hidden form field to contain the dotransfer data. Test plan 1/ Set AutomaticItemReturn system preference is set to "Don't" 2/ Check in an item that belongs to another library, a dialog will ask you if you want to transfer. 3/ Click 'Yes, print slip' 4/ Look at the item record and note the status is 'Available'. 5/ Apply patch 6/ Follow steps 2 - 4 7/ Note the status is now 'In transit to...' 8/ Signoff Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk> Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
(In reply to Victor Grousset/tuxayo from comment #10) > Hum, actually I don't know how to test the second patch. «However, it does > need removing to prevent the re-triggering now.» > > Didn't found how to do a re-triggering when not having the second patch. I think Victor is right, the second patch touches code that isn't hit when we have an existing transfer - we hit the 'WrongTransfer' portion instead - dropping that and passing QA
Thanks Nick.. you guys were both right.. I hadn't taken a broad enough view of the code with that intuitive follow-up.. happy it's been dropped :)
The switch from input to button has been done on commit 10a9a1e147699bdb1fd2b58ab93fe87cb82074cf Bug 15821: Use Font Awesome icons in confirmation dialogs - Circulation Does it mean it's broken for 5 years? Additional question, shouldn't we remove the value="Yes" attribute from the buttons, to avoid confusion in the future?
*** Bug 28176 has been marked as a duplicate of this bug. ***
Waiting for answer on comment 14.
(In reply to Jonathan Druart from comment #14) > The switch from input to button has been done on > commit 10a9a1e147699bdb1fd2b58ab93fe87cb82074cf > Bug 15821: Use Font Awesome icons in confirmation dialogs - Circulation > > Does it mean it's broken for 5 years? > > Additional question, shouldn't we remove the value="Yes" attribute from the > buttons, to avoid confusion in the future? A git bisect traced it back to bug 24085 for me... so not 5 years.. but certainly since 19.11.02. Hmm, removing the 'value=Yes' is perhaps a good idea... I tried to be as noninvasive as I could as this template is plain confusing
Created attachment 119993 [details] [review] Bug 28064: (QA follow-up) Remove value from button To clarify that the value is not used on buttons that are not submit type we remove the value entirely.
Pushed to master for 21.05, thanks to everybody involved!
Pushed to 20.11.x for 20.11.06
Pushed to 20.05.x for 20.05.12
Backported: Pushed to 19.11.x branch for 19.11.18