Created attachment 92025 [details] Checking a hold for another library with HoldsAutoFill enabled If the HoldsAutoFill system preference is enabled, the hold confirmation dialogs on the check-in page are badly constructed, resulting in duplicate information and inconsistent displays. See attached screenshot
Created attachment 92028 [details] [review] Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled This patch corrects a problem with hold confirmation dialogs on the checkin page when the HoldsAutoFill system preference is enabled and the item being checked in has a hold at another library. The confirmation dialog is converted to a modal to match other confirmation information. As part of this process two whole sections of the template have been removed because they were redundant. To test, apply the patch and test the following circumstances both with HoldsAutoFill enabled AND disabled: - A hold for a patron at your library - A hold for a patron not at your library - With HoldsAutoFill ON, both the "OK" and "Print slip and confirm" buttons should dismiss the modal without reloading the page. - A hold which is already marked 'Waiting' - An item which needs to be transferred - An item which has already been transferred In all cases the confirmation modal should appear with correct information.
*** Bug 23209 has been marked as a duplicate of this bug. ***
Created attachment 92072 [details] [review] Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled This patch corrects a problem with hold confirmation dialogs on the checkin page when the HoldsAutoFill system preference is enabled and the item being checked in has a hold at another library. The confirmation dialog is converted to a modal to match other confirmation information. As part of this process two whole sections of the template have been removed because they were redundant. To test, apply the patch and test the following circumstances both with HoldsAutoFill enabled AND disabled: - A hold for a patron at your library - A hold for a patron not at your library - With HoldsAutoFill ON, both the "OK" and "Print slip and confirm" buttons should dismiss the modal without reloading the page. - A hold which is already marked 'Waiting' - An item which needs to be transferred - An item which has already been transferred In all cases the confirmation modal should appear with correct information. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Fixes the exposed issue.. Signing off.. thanks Owen
Patch doesn't apply for me :( Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled error: sha1 information is lacking or useless (koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt). error: could not build fake ancestor Patch failed at 0001 Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-23434-Hold-confirmation-dialog-problem-if-Hold-wUIahn.patch
Created attachment 92082 [details] [review] Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled This patch corrects a problem with hold confirmation dialogs on the checkin page when the HoldsAutoFill system preference is enabled and the item being checked in has a hold at another library. The confirmation dialog is converted to a modal to match other confirmation information. As part of this process two whole sections of the template have been removed because they were redundant. To test, apply the patch and test the following circumstances both with HoldsAutoFill enabled AND disabled: - A hold for a patron at your library - A hold for a patron not at your library - With HoldsAutoFill ON, both the "OK" and "Print slip and confirm" buttons should dismiss the modal without reloading the page. - A hold which is already marked 'Waiting' - An item which needs to be transferred - An item which has already been transferred In all cases the confirmation modal should appear with correct information. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
hmm.. try now?
Created attachment 92093 [details] [review] Bug 23434: Hold confirmation dialog problem if HoldsAutoFill is enabled This patch corrects a problem with hold confirmation dialogs on the checkin page when the HoldsAutoFill system preference is enabled and the item being checked in has a hold at another library. The confirmation dialog is converted to a modal to match other confirmation information. As part of this process two whole sections of the template have been removed because they were redundant. To test, apply the patch and test the following circumstances both with HoldsAutoFill enabled AND disabled: - A hold for a patron at your library - A hold for a patron not at your library - With HoldsAutoFill ON, both the "OK" and "Print slip and confirm" buttons should dismiss the modal without reloading the page. - A hold which is already marked 'Waiting' - An item which needs to be transferred - An item which has already been transferred In all cases the confirmation modal should appear with correct information. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Nice work! Pushed to master for 19.11.00
Depends on Bug 23399 not in 19.05.x