[Bug 38842] New: Refactor modal logic in returns.tt / returns.pl
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Bug ID: 38842 Summary: Refactor modal logic in returns.tt / returns.pl Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: koha-bugs@lists.koha-community.org Reporter: emily.lamancusa@montgomerycountymd.gov QA Contact: testopia@bugs.koha-community.org Depends on: 38588, 38789, 38793 The logic for displaying modals on the checkin page is badly in need of refactoring. There are 10 separate modals coded in returns.tt, plus an additional 2 modal include files. There is also at least one parameter (found) that is duplicated for completely different meanings in different contexts, and several other similar-sounding parameters in different contexts whose meaning is no longer clear without code tracing how the value was assigned. All of this leads to a lot of code duplication and error-prone code, and makes it very confusing to follow the template/controller logic when developing or debugging. We should refactor down to one modal with clear logic for filling in its contents. See also comments on bug 38588 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38588 [Bug 38588] Checkin that triggers a transfer => print slip => Internal server error https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38789 [Bug 38789] Wrong Transfer modal does not show https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 [Bug 38793] Transfer silently not canceled when TransfersBlockCirc = "don't block" and AutomaticConfirmTransfer = "do automatically confirm" -- 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=38842 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38806 -- 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=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|koha-bugs@lists.koha-commun |emily.lamancusa@montgomeryc |ity.org |ountymd.gov -- 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=38842 --- Comment #1 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 178875 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178875&action=edit Bug 38842: Add reusable modal wrapper This patch adds the block modal_wrapper to html_helpers.inc. Minimal usage: [% WRAPPER modal_wrapper modal_id=<id> modal_header_contents=<contents> %] <modal body goes here> [ % END %] The above will produce an informational modal with an "OK" button to dismiss, and no actions taken. Optional parameters to add functionality to the modal: noblock=1 - if the modal should not block modal_action - if the modal should submit a form, the action url for the form To add a "confirm" button that will submit the modal form: modal_confirm_text - text to show on the button (must be specified) modal_confirm_name - (optional) specify a name attribute modal_confirm_val - (optional) specify a value attribute modal_confirm_accesskey - (optional) specify an accesskey attribute To add a "print" button that will open a print window to the specified url: modal_print_text - text to show on the button (must be specified) modal_print_url - url of the page to print (must be specified) modal_print_name - (optional) specify a name attribute modal_print_accesskey - (optional) specify an accesskey attribute To add a "cancel/deny/dismiss" button: modal_deny_text - text to show on the button (must be specified) modal_deny_action - "submit" if the deny button should submit the modal (to take some denial/cancellation action) - "dismiss" if the deny button should dismiss the modal without submitting the form - This parameter can be omitted if the button should neither submit nor dismiss the modal (for example, if the button click will be handled with JS) modal_deny_name - (optional) specify a name attribute modal_deny_val - (optional) specify a value attribute modal_deny_accesskey - (optional) specify an accesskey attribute If the above generic buttons do not suffice, the below parameters can be used in addition or instead of the above options to specify custom button code and/or other customized footer content: modal_custom_confirm modal_custom_utility_button modal_custom_deny modal_footer_append -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #2 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Work in progress for a reusable modal wrapper - posting for feedback! I tried to walk the line between flexibility and reusability, but I'm definitely open to feedback on the overall structure and how data is passed. I wasn't really sure about how to do the print button, since existing modals seem to do it in many different ways. Is a standardized print button realistic, or are different methods really necessary depending on the circumstances? See the commit message for usage. Most inputs that should be included in the modal form should usually be included in the modal body, though modal_footer_append can be used to add additional inputs into the footer. The <form> tag itself should NOT be included in the modal body; it is already included in the wrapper. Most components within the modal have a predictable id, based on the modal_id parameter, so that they can easily be targeted with Javascript. Any feedback is welcome and appreciated! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178875|0 |1 is obsolete| | --- Comment #3 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179084 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179084&action=edit Bug 38842: Add reusable modal wrapper This patch adds the block modal_wrapper to html_helpers.inc. NOTE: The caller is responsible for sanitizing all data inputs. Minimal usage: [% WRAPPER modal_wrapper modal_id=<id> modal_header_contents=<contents> %] <modal body goes here> [ % END %] The above will produce an informational modal with an "OK" button to dismiss, and no actions taken. Optional parameters to add functionality to the modal: noblock=1 - if the modal should not block modal_action - if the modal should submit a form, the action url for the form To add a "confirm" button that will submit the modal form: modal_confirm_text - text to show on the button (must be specified) modal_confirm_name - (optional) specify a name attribute modal_confirm_val - (optional) specify a value attribute modal_confirm_accesskey - (optional) specify an accesskey attribute To add a "print" button that will open a print window to the specified url: modal_print_text - text to show on the button (must be specified) modal_print_url - url of the page to print (must be specified) modal_print_name - (optional) specify a name attribute modal_print_accesskey - (optional) specify an accesskey attribute To add a "cancel/deny/dismiss" button: modal_deny_text - text to show on the button (must be specified) modal_deny_action - "submit" if the deny button should submit the modal (to take some denial/cancellation action) - "dismiss" if the deny button should dismiss the modal without submitting the form - This parameter can be omitted if the button should neither submit nor dismiss the modal (for example, if the button click will be handled with JS) modal_deny_name - (optional) specify a name attribute modal_deny_val - (optional) specify a value attribute modal_deny_accesskey - (optional) specify an accesskey attribute If the above generic buttons do not suffice, the below parameters can be used in addition or instead of the above options to specify custom button code and/or other customized footer content: modal_custom_confirm modal_custom_utility_button modal_custom_deny modal_footer_append -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #4 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179085 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179085&action=edit Bug 38842: Add block to DRY out checkin page pass-through data There are a number of variable values that need to get passed back to the controller after submitting a modal to maintain the checkin page's state. Currently, all of these inputs are manually coded for each modal. Add a Template Toolkit block that can be used instead to add all of these mandatory "pass-through" values. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #5 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179086 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179086&action=edit Bug 38842: Use new reusable components for hold-found2 modal Refactor the code for hold-found2 to use the new modal_wrapper and passthrough_data block as a proof of concept. The modal is also renamed hold-found-modal. To test: Setup: 0. Set system preferences: - HoldsAutoFill = Don't - ShowAllCheckins = Show 1. Find a biblio record with multiple items 2. Set the homebranch on all of those items to the logged-in branch 3. Place two holds on that record: - One for pickup at the logged-in branch (Hold A) - One for pickup at a different branch (Hold B) 4. Keep the tab for the biblio record open, and open a new tab for checkins 5. Check in an item from that bib 6. Take a screenshot of the modal on main for easy comparison 7. Ignore the hold 8. Apply patches Test a hold for pickup at the logged-in branch: 9. Check in the item again --> Confirm that the new modal contains all the correct information for Hold A. The only change in the modal should be that the title is now in the modal body instead of the modal header. 10. Open all of the links in the modal body in new tabs. --> Confirm the links all work as expected, then close those tabs 11. Click to ignore the hold --> Confirm that the checkins table displays correctly 12. Reload the Holds tab of the biblio record --> Confirm the holds are unchanged 13. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 14. Check in the item again and click the button to confirm the hold --> Confirm that the checkins table displays correctly 15. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting 16. Revert the waiting status on Hold A 17. Check in the item again 18. Click the button to confirm and print slip --> Confirm the print dialog appears and slip information is correct 19. Cancel the print dialog --> Confirm that the checkins table displays correctly 20. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting Test a hold for pickup at a different branch: 21. Check in a different item from that bib --> Confirm that the new modal contains all the correct information for Hold B, and correctly states that the item needs to be transferred 22. Click to ignore the hold --> Confirm that the checkins table displays correctly 23. Reload the Holds tab of the biblio record --> Confirm the hold is unchanged 24. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 25. Check in the item again and click the button to confirm and transfer --> Confirm that the checkins table displays correctly 26. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 27. Revert the transit status on Hold B 28. Check in the item again 29. Click the button to print slip, transfer, and confirm --> Confirm the print dialog appears and slip information is correct 30. Cancel the print dialog --> Confirm that the checkins table displays correctly 31. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 32. Change your logged-in branch to match Hold B's pickup location 33. Check in the item again --> Confirm the modal still contains all the correct information for Hold B and does not say it needs to be transferred 34. Click to print slip and confirm --> Confirm that the print dialog appears and looks correct 35. Cancel the print dialog 36. Reload the Holds tab of the biblio record --> Confirm that both holds are now Waiting 37. Sign off :D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179086|0 |1 is obsolete| | --- Comment #6 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179087 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179087&action=edit Bug 38842: Use new reusable components for hold-found2 modal Refactor the code for hold-found2 to use the new modal_wrapper and passthrough_data block as a proof of concept. The modal is also renamed hold-found-modal. To test: Setup: 0. Set system preferences: - HoldsAutoFill = Don't - ShowAllCheckins = Show 1. Find a biblio record with multiple items 2. Set the homebranch on all of those items to the logged-in branch 3. Place two holds on that record: - One for pickup at the logged-in branch (Hold A) - One for pickup at a different branch (Hold B) 4. Keep the tab for the biblio record open, and open a new tab for checkins 5. Check in an item from that bib 6. Take a screenshot of the modal on main for easy comparison 7. Ignore the hold 8. Apply patches Test a hold for pickup at the logged-in branch: 9. Check in the item again --> Confirm that the new modal contains all the correct information for Hold A. The only change in the modal should be that the title is now in the modal body instead of the modal header. 10. Open all of the links in the modal body in new tabs. --> Confirm the links all work as expected, then close those tabs 11. Click to ignore the hold --> Confirm that the checkins table displays correctly 12. Reload the Holds tab of the biblio record --> Confirm the holds are unchanged 13. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 14. Check in the item again and click the button to confirm the hold --> Confirm that the checkins table displays correctly 15. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting 16. Revert the waiting status on Hold A 17. Check in the item again 18. Click the button to confirm and print slip --> Confirm the print dialog appears and slip information is correct 19. Cancel the print dialog --> Confirm that the checkins table displays correctly 20. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting Test a hold for pickup at a different branch: 21. Check in a different item from that bib --> Confirm that the new modal contains all the correct information for Hold B, and correctly states that the item needs to be transferred 22. Click to ignore the hold --> Confirm that the checkins table displays correctly 23. Reload the Holds tab of the biblio record --> Confirm the hold is unchanged 24. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 25. Check in the item again and click the button to confirm and transfer --> Confirm that the checkins table displays correctly 26. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 27. Revert the transit status on Hold B 28. Check in the item again 29. Click the button to print slip, transfer, and confirm --> Confirm the print dialog appears and slip information is correct 30. Cancel the print dialog --> Confirm that the checkins table displays correctly 31. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 32. Change your logged-in branch to match Hold B's pickup location 33. Check in the item again --> Confirm the modal still contains all the correct information for Hold B and does not say it needs to be transferred 34. Click to print slip and confirm --> Confirm that the print dialog appears and looks correct 35. Cancel the print dialog 36. Reload the Holds tab of the biblio record --> Confirm that both holds are now Waiting 37. Sign off :D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff --- Comment #7 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- I think this is ready for testing and code review as a proof of concept. When this code is agreed upon, I'll make a follow-up bug to refactor the rest of the modals on returns.tt -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #8 from Owen Leonard <oleonard@myacpl.org> --- Taking a quick look at the patch... This will not be translatable text: [% confirm_button_text = 'Confirm hold and transfer' %] This works: [% confirm_button_text = t('Confirm hold and transfer') %] This also will not work: [% print_button = '<button type="button" class="btn btn-default print" accesskey="p"> <i class="fa fa-print"></i> Print slip, transfer, and confirm (P) </button>' %] I think it would work to concatenate the elements: [% print_button = '<button type="button" class="btn btn-default print" accesskey="p"> <i class="fa fa-print"></i> ' _ t('Print slip, transfer, and confirm') _ ' (P) </button>' %] -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #9 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179127 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179127&action=edit Bug 38842: (follow-up) Fix translatability Add t() calls to make text translatable -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #10 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Thanks for catching that, Owen! I submitted a follow-up patch to make the text translatable. Setting back to NSO -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com --- Comment #11 from Jonathan Druart <jonathan.druart@gmail.com> --- You should use the uri/html filters when needed, not always $raw. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #12 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- (In reply to Jonathan Druart from comment #11)
You should use the uri/html filters when needed, not always $raw.
Oop, thanks for catching that. Some of them do need to be $raw as the caller needs to be able to pass in a complete url string or HTML, but you're right, a lot of them don't need to be. I'll upload a follow-up patch shortly. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179084|0 |1 is obsolete| | --- Comment #13 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179520 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179520&action=edit Bug 38842: Add reusable modal wrapper This patch adds the block modal_wrapper to html_helpers.inc. NOTE: The caller is responsible for sanitizing all data inputs. Minimal usage: [% WRAPPER modal_wrapper modal_id=<id> modal_header_contents=<contents> %] <modal body goes here> [ % END %] The above will produce an informational modal with an "OK" button to dismiss, and no actions taken. Optional parameters to add functionality to the modal: noblock=1 - if the modal should not block modal_action - if the modal should submit a form, the action url for the form To add a "confirm" button that will submit the modal form: modal_confirm_text - text to show on the button (must be specified) modal_confirm_name - (optional) specify a name attribute modal_confirm_val - (optional) specify a value attribute modal_confirm_accesskey - (optional) specify an accesskey attribute To add a "print" button that will open a print window to the specified url: modal_print_text - text to show on the button (must be specified) modal_print_url - url of the page to print (must be specified) modal_print_name - (optional) specify a name attribute modal_print_accesskey - (optional) specify an accesskey attribute To add a "cancel/deny/dismiss" button: modal_deny_text - text to show on the button (must be specified) modal_deny_action - "submit" if the deny button should submit the modal (to take some denial/cancellation action) - "dismiss" if the deny button should dismiss the modal without submitting the form - This parameter can be omitted if the button should neither submit nor dismiss the modal (for example, if the button click will be handled with JS) modal_deny_name - (optional) specify a name attribute modal_deny_val - (optional) specify a value attribute modal_deny_accesskey - (optional) specify an accesskey attribute If the above generic buttons do not suffice, the below parameters can be used in addition or instead of the above options to specify custom button code and/or other customized footer content: modal_custom_confirm modal_custom_utility_button modal_custom_deny modal_footer_append -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179085|0 |1 is obsolete| | --- Comment #14 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179521 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179521&action=edit Bug 38842: Add block to DRY out checkin page pass-through data There are a number of variable values that need to get passed back to the controller after submitting a modal to maintain the checkin page's state. Currently, all of these inputs are manually coded for each modal. Add a Template Toolkit block that can be used instead to add all of these mandatory "pass-through" values. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179087|0 |1 is obsolete| | --- Comment #15 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179523 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179523&action=edit Bug 38842: Use new reusable components for hold-found2 modal Refactor the code for hold-found2 to use the new modal_wrapper and passthrough_data block as a proof of concept. The modal is also renamed hold-found-modal. To test: Setup: 0. Set system preferences: - HoldsAutoFill = Don't - ShowAllCheckins = Show 1. Find a biblio record with multiple items 2. Set the homebranch on all of those items to the logged-in branch 3. Place two holds on that record: - One for pickup at the logged-in branch (Hold A) - One for pickup at a different branch (Hold B) 4. Keep the tab for the biblio record open, and open a new tab for checkins 5. Check in an item from that bib 6. Take a screenshot of the modal on main for easy comparison 7. Ignore the hold 8. Apply patches Test a hold for pickup at the logged-in branch: 9. Check in the item again --> Confirm that the new modal contains all the correct information for Hold A. The only change in the modal should be that the title is now in the modal body instead of the modal header. 10. Open all of the links in the modal body in new tabs. --> Confirm the links all work as expected, then close those tabs 11. Click to ignore the hold --> Confirm that the checkins table displays correctly 12. Reload the Holds tab of the biblio record --> Confirm the holds are unchanged 13. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 14. Check in the item again and click the button to confirm the hold --> Confirm that the checkins table displays correctly 15. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting 16. Revert the waiting status on Hold A 17. Check in the item again 18. Click the button to confirm and print slip --> Confirm the print dialog appears and slip information is correct 19. Cancel the print dialog --> Confirm that the checkins table displays correctly 20. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting Test a hold for pickup at a different branch: 21. Check in a different item from that bib --> Confirm that the new modal contains all the correct information for Hold B, and correctly states that the item needs to be transferred 22. Click to ignore the hold --> Confirm that the checkins table displays correctly 23. Reload the Holds tab of the biblio record --> Confirm the hold is unchanged 24. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 25. Check in the item again and click the button to confirm and transfer --> Confirm that the checkins table displays correctly 26. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 27. Revert the transit status on Hold B 28. Check in the item again 29. Click the button to print slip, transfer, and confirm --> Confirm the print dialog appears and slip information is correct 30. Cancel the print dialog --> Confirm that the checkins table displays correctly 31. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 32. Change your logged-in branch to match Hold B's pickup location 33. Check in the item again --> Confirm the modal still contains all the correct information for Hold B and does not say it needs to be transferred 34. Click to print slip and confirm --> Confirm that the print dialog appears and looks correct 35. Cancel the print dialog 36. Reload the Holds tab of the biblio record --> Confirm that both holds are now Waiting 37. Sign off :D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179127|0 |1 is obsolete| | --- Comment #16 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179524 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179524&action=edit Bug 38842: (follow-up) Fix translatability Add t() calls to make text translatable -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #17 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 179526 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179526&action=edit Bug 38842: (follow-up) Fix TT filters in modal_wrapper Use html filters for most of the parameter variables, when possible. The following parameters do need to be used raw, as they are expected to contain HTML code or complete url strings: modal_action modal_custom_confirm modal_print_url modal_custom_utility_button modal_custom_deny modal_footer_append If the caller includes any inputs from elsewhere in the above parameters, the caller must filter those inputs using the appropriate TT filter. This patch also adjusts the handling of header data so that only plain text should be passed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179520|0 |1 is obsolete| | --- Comment #18 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179538 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179538&action=edit Bug 38842: Add reusable modal wrapper This patch adds the block modal_wrapper to html_helpers.inc. NOTE: The caller is responsible for sanitizing all data inputs. Minimal usage: [% WRAPPER modal_wrapper modal_id=<id> modal_header_contents=<contents> %] <modal body goes here> [ % END %] The above will produce an informational modal with an "OK" button to dismiss, and no actions taken. Optional parameters to add functionality to the modal: noblock=1 - if the modal should not block modal_action - if the modal should submit a form, the action url for the form To add a "confirm" button that will submit the modal form: modal_confirm_text - text to show on the button (must be specified) modal_confirm_name - (optional) specify a name attribute modal_confirm_val - (optional) specify a value attribute modal_confirm_accesskey - (optional) specify an accesskey attribute To add a "print" button that will open a print window to the specified url: modal_print_text - text to show on the button (must be specified) modal_print_url - url of the page to print (must be specified) modal_print_name - (optional) specify a name attribute modal_print_accesskey - (optional) specify an accesskey attribute To add a "cancel/deny/dismiss" button: modal_deny_text - text to show on the button (must be specified) modal_deny_action - "submit" if the deny button should submit the modal (to take some denial/cancellation action) - "dismiss" if the deny button should dismiss the modal without submitting the form - This parameter can be omitted if the button should neither submit nor dismiss the modal (for example, if the button click will be handled with JS) modal_deny_name - (optional) specify a name attribute modal_deny_val - (optional) specify a value attribute modal_deny_accesskey - (optional) specify an accesskey attribute If the above generic buttons do not suffice, the below parameters can be used in addition or instead of the above options to specify custom button code and/or other customized footer content: modal_custom_confirm modal_custom_utility_button modal_custom_deny modal_footer_append Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179521|0 |1 is obsolete| | --- Comment #19 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179539 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179539&action=edit Bug 38842: Add block to DRY out checkin page pass-through data There are a number of variable values that need to get passed back to the controller after submitting a modal to maintain the checkin page's state. Currently, all of these inputs are manually coded for each modal. Add a Template Toolkit block that can be used instead to add all of these mandatory "pass-through" values. Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179523|0 |1 is obsolete| | --- Comment #20 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179540 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179540&action=edit Bug 38842: Use new reusable components for hold-found2 modal Refactor the code for hold-found2 to use the new modal_wrapper and passthrough_data block as a proof of concept. The modal is also renamed hold-found-modal. To test: Setup: 0. Set system preferences: - HoldsAutoFill = Don't - ShowAllCheckins = Show 1. Find a biblio record with multiple items 2. Set the homebranch on all of those items to the logged-in branch 3. Place two holds on that record: - One for pickup at the logged-in branch (Hold A) - One for pickup at a different branch (Hold B) 4. Keep the tab for the biblio record open, and open a new tab for checkins 5. Check in an item from that bib 6. Take a screenshot of the modal on main for easy comparison 7. Ignore the hold 8. Apply patches Test a hold for pickup at the logged-in branch: 9. Check in the item again --> Confirm that the new modal contains all the correct information for Hold A. The only change in the modal should be that the title is now in the modal body instead of the modal header. 10. Open all of the links in the modal body in new tabs. --> Confirm the links all work as expected, then close those tabs 11. Click to ignore the hold --> Confirm that the checkins table displays correctly 12. Reload the Holds tab of the biblio record --> Confirm the holds are unchanged 13. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 14. Check in the item again and click the button to confirm the hold --> Confirm that the checkins table displays correctly 15. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting 16. Revert the waiting status on Hold A 17. Check in the item again 18. Click the button to confirm and print slip --> Confirm the print dialog appears and slip information is correct 19. Cancel the print dialog --> Confirm that the checkins table displays correctly 20. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting Test a hold for pickup at a different branch: 21. Check in a different item from that bib --> Confirm that the new modal contains all the correct information for Hold B, and correctly states that the item needs to be transferred 22. Click to ignore the hold --> Confirm that the checkins table displays correctly 23. Reload the Holds tab of the biblio record --> Confirm the hold is unchanged 24. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 25. Check in the item again and click the button to confirm and transfer --> Confirm that the checkins table displays correctly 26. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 27. Revert the transit status on Hold B 28. Check in the item again 29. Click the button to print slip, transfer, and confirm --> Confirm the print dialog appears and slip information is correct 30. Cancel the print dialog --> Confirm that the checkins table displays correctly 31. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 32. Change your logged-in branch to match Hold B's pickup location 33. Check in the item again --> Confirm the modal still contains all the correct information for Hold B and does not say it needs to be transferred 34. Click to print slip and confirm --> Confirm that the print dialog appears and looks correct 35. Cancel the print dialog 36. Reload the Holds tab of the biblio record --> Confirm that both holds are now Waiting 37. Sign off :D Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179524|0 |1 is obsolete| | --- Comment #21 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179541 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179541&action=edit Bug 38842: (follow-up) Fix translatability Add t() calls to make text translatable Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179526|0 |1 is obsolete| | --- Comment #22 from Baptiste Wojtkowski (bwoj) <baptiste.wojtkowski@biblibre.com> --- Created attachment 179542 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=179542&action=edit Bug 38842: (follow-up) Fix TT filters in modal_wrapper Use html filters for most of the parameter variables, when possible. The following parameters do need to be used raw, as they are expected to contain HTML code or complete url strings: modal_action modal_custom_confirm modal_print_url modal_custom_utility_button modal_custom_deny modal_footer_append If the caller includes any inputs from elsewhere in the above parameters, the caller must filter those inputs using the appropriate TT filter. This patch also adjusts the handling of header data so that only plain text should be passed. Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Paul Derscheid <paul.derscheid@lmscloud.de> 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=38842 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179538|0 |1 is obsolete| | --- Comment #23 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 180752 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180752&action=edit Bug 38842: Add reusable modal wrapper This patch adds the block modal_wrapper to html_helpers.inc. NOTE: The caller is responsible for sanitizing all data inputs. Minimal usage: [% WRAPPER modal_wrapper modal_id=<id> modal_header_contents=<contents> %] <modal body goes here> [ % END %] The above will produce an informational modal with an "OK" button to dismiss, and no actions taken. Optional parameters to add functionality to the modal: noblock=1 - if the modal should not block modal_action - if the modal should submit a form, the action url for the form To add a "confirm" button that will submit the modal form: modal_confirm_text - text to show on the button (must be specified) modal_confirm_name - (optional) specify a name attribute modal_confirm_val - (optional) specify a value attribute modal_confirm_accesskey - (optional) specify an accesskey attribute To add a "print" button that will open a print window to the specified url: modal_print_text - text to show on the button (must be specified) modal_print_url - url of the page to print (must be specified) modal_print_name - (optional) specify a name attribute modal_print_accesskey - (optional) specify an accesskey attribute To add a "cancel/deny/dismiss" button: modal_deny_text - text to show on the button (must be specified) modal_deny_action - "submit" if the deny button should submit the modal (to take some denial/cancellation action) - "dismiss" if the deny button should dismiss the modal without submitting the form - This parameter can be omitted if the button should neither submit nor dismiss the modal (for example, if the button click will be handled with JS) modal_deny_name - (optional) specify a name attribute modal_deny_val - (optional) specify a value attribute modal_deny_accesskey - (optional) specify an accesskey attribute If the above generic buttons do not suffice, the below parameters can be used in addition or instead of the above options to specify custom button code and/or other customized footer content: modal_custom_confirm modal_custom_utility_button modal_custom_deny modal_footer_append Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179539|0 |1 is obsolete| | --- Comment #24 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 180753 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180753&action=edit Bug 38842: Add block to DRY out checkin page pass-through data There are a number of variable values that need to get passed back to the controller after submitting a modal to maintain the checkin page's state. Currently, all of these inputs are manually coded for each modal. Add a Template Toolkit block that can be used instead to add all of these mandatory "pass-through" values. Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179540|0 |1 is obsolete| | --- Comment #25 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 180754 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180754&action=edit Bug 38842: Use new reusable components for hold-found2 modal Refactor the code for hold-found2 to use the new modal_wrapper and passthrough_data block as a proof of concept. The modal is also renamed hold-found-modal. To test: Setup: 0. Set system preferences: - HoldsAutoFill = Don't - ShowAllCheckins = Show 1. Find a biblio record with multiple items 2. Set the homebranch on all of those items to the logged-in branch 3. Place two holds on that record: - One for pickup at the logged-in branch (Hold A) - One for pickup at a different branch (Hold B) 4. Keep the tab for the biblio record open, and open a new tab for checkins 5. Check in an item from that bib 6. Take a screenshot of the modal on main for easy comparison 7. Ignore the hold 8. Apply patches Test a hold for pickup at the logged-in branch: 9. Check in the item again --> Confirm that the new modal contains all the correct information for Hold A. The only change in the modal should be that the title is now in the modal body instead of the modal header. 10. Open all of the links in the modal body in new tabs. --> Confirm the links all work as expected, then close those tabs 11. Click to ignore the hold --> Confirm that the checkins table displays correctly 12. Reload the Holds tab of the biblio record --> Confirm the holds are unchanged 13. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 14. Check in the item again and click the button to confirm the hold --> Confirm that the checkins table displays correctly 15. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting 16. Revert the waiting status on Hold A 17. Check in the item again 18. Click the button to confirm and print slip --> Confirm the print dialog appears and slip information is correct 19. Cancel the print dialog --> Confirm that the checkins table displays correctly 20. Reload the Holds tab of the biblio record --> Confirm Hold A is now set to Waiting Test a hold for pickup at a different branch: 21. Check in a different item from that bib --> Confirm that the new modal contains all the correct information for Hold B, and correctly states that the item needs to be transferred 22. Click to ignore the hold --> Confirm that the checkins table displays correctly 23. Reload the Holds tab of the biblio record --> Confirm the hold is unchanged 24. Switch to the Normal tab of the biblio record --> Confirm the item still shows as Available 25. Check in the item again and click the button to confirm and transfer --> Confirm that the checkins table displays correctly 26. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 27. Revert the transit status on Hold B 28. Check in the item again 29. Click the button to print slip, transfer, and confirm --> Confirm the print dialog appears and slip information is correct 30. Cancel the print dialog --> Confirm that the checkins table displays correctly 31. Reload the Holds tab of the biblio record --> Confirm Hold B is now set to in-transit 32. Change your logged-in branch to match Hold B's pickup location 33. Check in the item again --> Confirm the modal still contains all the correct information for Hold B and does not say it needs to be transferred 34. Click to print slip and confirm --> Confirm that the print dialog appears and looks correct 35. Cancel the print dialog 36. Reload the Holds tab of the biblio record --> Confirm that both holds are now Waiting 37. Sign off :D Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179541|0 |1 is obsolete| | --- Comment #26 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 180755 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180755&action=edit Bug 38842: (follow-up) Fix translatability Add t() calls to make text translatable Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #179542|0 |1 is obsolete| | --- Comment #27 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 180756 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180756&action=edit Bug 38842: (follow-up) Fix TT filters in modal_wrapper Use html filters for most of the parameter variables, when possible. The following parameters do need to be used raw, as they are expected to contain HTML code or complete url strings: modal_action modal_custom_confirm modal_print_url modal_custom_utility_button modal_custom_deny modal_footer_append If the caller includes any inputs from elsewhere in the above parameters, the caller must filter those inputs using the appropriate TT filter. This patch also adjusts the handling of header data so that only plain text should be passed. Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Medium patch QA Contact|testopia@bugs.koha-communit |paul.derscheid@lmscloud.de |y.org | Keywords| |RM_priority CC| |paul.derscheid@lmscloud.de --- Comment #28 from Paul Derscheid <paul.derscheid@lmscloud.de> --- This is a big leap for modals in Koha, the implementation of the wrapper is great, maybe still needs refinement in some places but not worth not PQAing this right now :) I was starting to write a cypress test which would be nice but don't know how to do the syspref assertions. That probably requires selenium (ugh). Just went over the test plan again after perusing the files and this does everything it says it does and is even a UI improvement compared to the previous iteration. Great job Emily! Some things I still crave: - Similar documentation with one simple and one complex example following the style of the other bootstrap component wrappers in html_helpers.inc. Would be important for quickly using this wrapper to refactor, I think. - Would be great if we had some kind of test in place to make sure we do not introduce regressions in later versions. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39613 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39613 [Bug 39613] Cover modal logic in returns.tt / returns.pl with Cypress tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Bug 38842 depends on bug 38588, which changed state. Bug 38588 Summary: Checkin that triggers a transfer => print slip => Internal server error https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38588 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=38842 --- Comment #29 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Paul Derscheid from comment #28)
This is a big leap for modals in Koha, the implementation of the wrapper is great, maybe still needs refinement in some places but not worth not PQAing this right now :)
I was starting to write a cypress test which would be nice but don't know how to do the syspref assertions. That probably requires selenium (ugh).
Search "ExtendedPatronAttributes" in t/cypress/integration/KohaTable/PatronSearch_spec.ts for an example. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |25.05.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=38842 --- Comment #30 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 25.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed --- Comment #31 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Emily and all, We seem to have a failing test here: not ok 2 - The <form> in the following files are missing it's corresponding op parameter, or op does not start with 'cud-' (see bug 34478) # Failed test 'The <form> in the following files are missing it's corresponding op parameter, or op does not start with 'cud-' (see bug 34478)' # at xt/find-missing-op-in-forms.t line 44. # got: '1' # expected: '0' # $VAR1 = 'koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers.inc:638'; # Looks like you failed 1 test of 2. Please take a look! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #32 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 181658 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=181658&action=edit Bug 38842: Add a op=cud-null to the form This will make xt/find-missing-op-in-forms.t pass But also enforce the use of a op=cud- parameter. It is at the end of the form element, so if another is passed in the modal body the one passed will get retrieved properly by CGI->param -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #33 from Jonathan Druart <jonathan.druart@gmail.com> --- Please test and confirm this patch before push. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #181658|0 |1 is obsolete| | --- Comment #34 from David Nind <david@davidnind.com> --- Created attachment 181661 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=181661&action=edit Bug 38842: Add a op=cud-null to the form This will make xt/find-missing-op-in-forms.t pass But also enforce the use of a op=cud- parameter. It is at the end of the form element, so if another is passed in the modal body the one passed will get retrieved properly by CGI->param Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #35 from David Nind <david@davidnind.com> --- The tests now pass after the patch. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed, | |RM_priority | --- Comment #36 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Follow-up pushed to main! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Refactor modal logic in |Add reusable modal wrapper |returns.tt / returns.pl | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 --- Comment #37 from Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> --- Thank you Jonathan and David for jumping in with follow-up! I think it is right to force the use of an op=cud- parameter - the form tag does specify POST, which is what flagged the test in the first place. I can't think of any reason why one would want to submit a form in a modal rather than dismiss the modal, if not to confirm a CUD action. If there is, we'll need a separate bug to add support for that. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39854 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39854 [Bug 39854] Add documentation for reusable modal wrapper -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |rel_24_11_candidate --- Comment #38 from Lisette Scheer <lisette@bywatersolutions.com> --- Requesting backport as this patch fixes bug 38806, which prevents cancelling transfers on returns.pl -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |release-notes-needed -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Bug 38842 depends on bug 38789, which changed state. Bug 38789 Summary: Wrong Transfer modal does not show https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38789 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |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=38842 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m --- Comment #39 from Fridolin Somers <fridolin.somers@biblibre.com> --- (In reply to Lisette Scheer from comment #38)
Requesting backport as this patch fixes bug 38806, which prevents cancelling transfers on returns.pl
Ich this is a medium patch, changes a lot the returns page. I think backporting is too risky for LTS stability. Maybe Bug 38806 can be fixed on 24.11.x without this one ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Bug 38842 depends on bug 38793, which changed state. Bug 38793 Summary: When setting up automatic confirmation of transfers when dismissing the modal. It prevents manual cancellation https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38793 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |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=38842 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |40739 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40739 [Bug 40739] Setting TransfersBlockCirc to 'Don't block' does not allow for scanning to continue -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Emily Lamancusa (emlam) <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|40739 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40739 [Bug 40739] Setting TransfersBlockCirc to 'Don't block' does not allow for scanning to continue -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED --- Comment #40 from David Nind <david@davidnind.com> --- I've changed to RESOLVED FIXED from needs documenting. As far as I can tell, this bug refactors how modals/pop-up windows are generated and makes things easier for developers and future changes. While there are possibly UI changes, I think any screenshots will get picked up with the ongoing work to automated screenshot capture. Please change back to Needs documenting if this is not the case. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38842 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|release-notes-needed | -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org