[Bug 37152] New: Delete-confirm should not start with 'cud-'
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Bug ID: 37152 Summary: Delete-confirm should not start with 'cud-' Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: emily.lamancusa@montgomerycountymd.gov QA Contact: testopia@bugs.koha-community.org Blocks: 36192 There are a number of pages that use the op delete_confirm to display a confirmation page before deleting an object, followed by the op cud-delete_confirm*ed* to actually perform the delete operation. A few pages slipped through that are expecting an op of cud-delete_confirm, which should not start with 'cud-': - acqui/basket.pl and basket.tt - opac/opac-suggestions.pl and opac-suggestions.tt - admin/auth-tag-structure.pl - admin/categories.pl - admin/aqcontract.pl - admin/marctagstructure.pl None of these broke functionality for me when I tested them - the first two because at least the .pl and .tt files align, and I'm not sure why the last four didn't break. Either way, they should still be brought in line with the coding guideline. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- 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=37152 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org --- Comment #1 from Phil Ringnalda <phil@chetcolibrary.org> --- aqcontract.pl doesn't seem to actually work, but the other three "work" because nothing done in the elsif ( $op eq 'cud-delete_confirm' ) is actually required. Deleting a tag, you just get a confirm page with "Tag: nnn" instead of "Tag: nnn liblibrarian" which isn't really noticeable, and if you delete an unused patron category it deletes, but if you delete a used patron category it tells you something went wrong and you should look at the logs to see why, because you were supposed to get a delete_confirm page telling you that you can't because it's used by 783 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=37152 --- Comment #2 from Phil Ringnalda <phil@chetcolibrary.org> --- And for acqui/basket and opac/opac-suggestions the bug is that they are using cud-delete_confim when they mean cud-delete_confirmed because they already did the confirmation in a javascript modal. Or, depending on how you look at it, they mean cud-delete. -- 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=37152 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Assignee|koha-bugs@lists.koha-commun |phil@chetcolibrary.org |ity.org | --- Comment #3 from Phil Ringnalda <phil@chetcolibrary.org> --- cud-delete. And major since you can't delete a contract. -- 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=37152 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 --- Comment #4 from Phil Ringnalda <phil@chetcolibrary.org> --- Created attachment 167987 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167987&action=edit Bug 37152: Can't delete an Acquisitions contract admin/aqcontract.pl expects the op cud-delete-confirm, but what's sent is the op delete-confirm because it's just a GET of the page that will actually do a cud op once it is confirmed. Test plan: 1. Without the patch, Acquisitions - Vendor search for My Vendor 2. Left Sidebar menu - Contracts - Add a contract 3. Fill in Name, Start date, End date, Save 4. On the line for the contract, click Delete 5. Note that the page that loads has no button for "Yes, delete contract" (or for anything else) 6. Apply patch, restart_all 7. Acquisitions - Vendor search for My Vendor 8. Left Sidebar menu, Contracts, click Delete, then Yes, delete contract 9. Vendor search for My Vendor, Left Sidebar Contracts, verify the contract is gone -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 --- Comment #5 from Phil Ringnalda <phil@chetcolibrary.org> --- Created attachment 167988 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167988&action=edit Bug 37152: Deleting framework tags expects a cud-delete-confirm op instead of delete-confirm The scripts for managing biblio and authority framework tag editing are expecting an op of cud-delete-confirm, but the op that is passed is the correct thing, delete-confirm, because it's a GET of a page where the confirmation will happen, not the later cud- operation. You can only see that the expected op is wrong because the confirmation page doesn't get the description of the tag. Test plan: 1. Without the patch, Administration - MARC bibliographic framework 2. Default framework Actions menu, MARC structure 3. In the row for 025, Actions menu, Delete 4. Note that the page which loads shows "Tag: 025" and "Description:" without actually having a description 5. Administration - Authority types 6. Default authority type Actions menu, MARC structure 7. In the row for 046, Actions menu, Delete 8. Note that the page that loads shows "Tag: 046" without the tag description 9. Apply patch, restart_all 10. With the patch, repeat steps 1-8, but this time note that you see the description of the tag, not just the number. For both, click Yes, delete, and verify that the tag is deleted. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 --- Comment #6 from Phil Ringnalda <phil@chetcolibrary.org> --- Created attachment 167989 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167989&action=edit Bug 37152: Deleting patron categories doesn't warn about categories in use You can't delete a patron category when it is in use, but because the script which handles delete confirmation is expecting the wrong op, cud-delete_confirm rather than delete_confirm, you don't get any warning, just a failure to delete error message. Test plan: 1. Without the patch, Administration - Patron categories 2. On the row for Staff, click Delete, Delete this category 3. Note an error message telling you to check the logs for details 4. Apply patch, restart_all 5. With the patch, repeat steps 1-2, note that instead of a button for Delete this category you get a warning that it is in use 6. In the list of categories, row for Board, click Delete, Delete this category 7. Note that the (unused) Board category was deleted -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 --- Comment #7 from Phil Ringnalda <phil@chetcolibrary.org> --- Created attachment 167990 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167990&action=edit Bug 37152: Aquisitions basket and OPAC suggestion deletion should use the op cud-delete Both deleting a basket in Aquisitions and deleting a suggestion in the OPAC take care of the confirmation in a javascript modal, rather than having a whole separate page for confirmation, so they should be using the op cud-delete rather than either cud-delete_confirm (which shouldn't ever be used) or delete_confirm (which they aren't doing, they already confirmed). Test plan: 1. There's no wrong behavior to see, so apply patch and restart_all 2. Aquisitions - Vendor search for My Vendor - Click My Basket 3. Click Delete basket, in the popup again Delete basket 4. Click Show baskets for vendor My Vendor and verify the basket is gone 5. OPAC - Your account - Purchase suggestions 6. Create a suggestion, then click the checkbox for it, Delete selected, confirm 7. Verify the suggestion was deleted -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167987|0 |1 is obsolete| | --- Comment #8 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 167993 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167993&action=edit Bug 37152: Can't delete an Acquisitions contract admin/aqcontract.pl expects the op cud-delete-confirm, but what's sent is the op delete-confirm because it's just a GET of the page that will actually do a cud op once it is confirmed. Test plan: 1. Without the patch, Acquisitions - Vendor search for My Vendor 2. Left Sidebar menu - Contracts - Add a contract 3. Fill in Name, Start date, End date, Save 4. On the line for the contract, click Delete 5. Note that the page that loads has no button for "Yes, delete contract" (or for anything else) 6. Apply patch, restart_all 7. Acquisitions - Vendor search for My Vendor 8. Left Sidebar menu, Contracts, click Delete, then Yes, delete contract 9. Vendor search for My Vendor, Left Sidebar Contracts, verify the contract is gone Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167988|0 |1 is obsolete| | --- Comment #9 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 167994 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167994&action=edit Bug 37152: Deleting framework tags expects a cud-delete-confirm op instead of delete-confirm The scripts for managing biblio and authority framework tag editing are expecting an op of cud-delete-confirm, but the op that is passed is the correct thing, delete-confirm, because it's a GET of a page where the confirmation will happen, not the later cud- operation. You can only see that the expected op is wrong because the confirmation page doesn't get the description of the tag. Test plan: 1. Without the patch, Administration - MARC bibliographic framework 2. Default framework Actions menu, MARC structure 3. In the row for 025, Actions menu, Delete 4. Note that the page which loads shows "Tag: 025" and "Description:" without actually having a description 5. Administration - Authority types 6. Default authority type Actions menu, MARC structure 7. In the row for 046, Actions menu, Delete 8. Note that the page that loads shows "Tag: 046" without the tag description 9. Apply patch, restart_all 10. With the patch, repeat steps 1-8, but this time note that you see the description of the tag, not just the number. For both, click Yes, delete, and verify that the tag is deleted. Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167989|0 |1 is obsolete| | --- Comment #10 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 167995 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167995&action=edit Bug 37152: Deleting patron categories doesn't warn about categories in use You can't delete a patron category when it is in use, but because the script which handles delete confirmation is expecting the wrong op, cud-delete_confirm rather than delete_confirm, you don't get any warning, just a failure to delete error message. Test plan: 1. Without the patch, Administration - Patron categories 2. On the row for Staff, click Delete, Delete this category 3. Note an error message telling you to check the logs for details 4. Apply patch, restart_all 5. With the patch, repeat steps 1-2, note that instead of a button for Delete this category you get a warning that it is in use 6. In the list of categories, row for Board, click Delete, Delete this category 7. Note that the (unused) Board category was deleted Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167990|0 |1 is obsolete| | --- Comment #11 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Created attachment 167996 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167996&action=edit Bug 37152: Aquisitions basket and OPAC suggestion deletion should use the op cud-delete Both deleting a basket in Aquisitions and deleting a suggestion in the OPAC take care of the confirmation in a javascript modal, rather than having a whole separate page for confirmation, so they should be using the op cud-delete rather than either cud-delete_confirm (which shouldn't ever be used) or delete_confirm (which they aren't doing, they already confirmed). Test plan: 1. There's no wrong behavior to see, so apply patch and restart_all 2. Aquisitions - Vendor search for My Vendor - Click My Basket 3. Click Delete basket, in the popup again Delete basket 4. Click Show baskets for vendor My Vendor and verify the basket is gone 5. OPAC - Your account - Purchase suggestions 6. Create a suggestion, then click the checkbox for it, Delete selected, confirm 7. Verify the suggestion was deleted Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #12 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Thanks, Phil! (for testing it more thoroughly than I did, the quick patchwriting, and the excellent commit messages :) ) Testing notes: After deleting a tag, marctagstructure.pl doesn't reload the framework properly - it has a heading showing the framework name, but nothing else. I think that's a separate bug, though. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 --- Comment #13 from Phil Ringnalda <phil@chetcolibrary.org> --- Filed that as bug 37161, since I don't see how the magic ever worked in the past, even though it did work. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Nick Clemens (kidclamp) <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=37152 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167993|0 |1 is obsolete| | --- Comment #14 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 168104 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168104&action=edit Bug 37152: Can't delete an Acquisitions contract admin/aqcontract.pl expects the op cud-delete-confirm, but what's sent is the op delete-confirm because it's just a GET of the page that will actually do a cud op once it is confirmed. Test plan: 1. Without the patch, Acquisitions - Vendor search for My Vendor 2. Left Sidebar menu - Contracts - Add a contract 3. Fill in Name, Start date, End date, Save 4. On the line for the contract, click Delete 5. Note that the page that loads has no button for "Yes, delete contract" (or for anything else) 6. Apply patch, restart_all 7. Acquisitions - Vendor search for My Vendor 8. Left Sidebar menu, Contracts, click Delete, then Yes, delete contract 9. Vendor search for My Vendor, Left Sidebar Contracts, verify the contract is gone Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> 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=37152 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167994|0 |1 is obsolete| | --- Comment #15 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 168105 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168105&action=edit Bug 37152: Deleting framework tags expects a cud-delete-confirm op instead of delete-confirm The scripts for managing biblio and authority framework tag editing are expecting an op of cud-delete-confirm, but the op that is passed is the correct thing, delete-confirm, because it's a GET of a page where the confirmation will happen, not the later cud- operation. You can only see that the expected op is wrong because the confirmation page doesn't get the description of the tag. Test plan: 1. Without the patch, Administration - MARC bibliographic framework 2. Default framework Actions menu, MARC structure 3. In the row for 025, Actions menu, Delete 4. Note that the page which loads shows "Tag: 025" and "Description:" without actually having a description 5. Administration - Authority types 6. Default authority type Actions menu, MARC structure 7. In the row for 046, Actions menu, Delete 8. Note that the page that loads shows "Tag: 046" without the tag description 9. Apply patch, restart_all 10. With the patch, repeat steps 1-8, but this time note that you see the description of the tag, not just the number. For both, click Yes, delete, and verify that the tag is deleted. Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> 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=37152 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167995|0 |1 is obsolete| | --- Comment #16 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 168106 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168106&action=edit Bug 37152: Deleting patron categories doesn't warn about categories in use You can't delete a patron category when it is in use, but because the script which handles delete confirmation is expecting the wrong op, cud-delete_confirm rather than delete_confirm, you don't get any warning, just a failure to delete error message. Test plan: 1. Without the patch, Administration - Patron categories 2. On the row for Staff, click Delete, Delete this category 3. Note an error message telling you to check the logs for details 4. Apply patch, restart_all 5. With the patch, repeat steps 1-2, note that instead of a button for Delete this category you get a warning that it is in use 6. In the list of categories, row for Board, click Delete, Delete this category 7. Note that the (unused) Board category was deleted Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> 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=37152 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167996|0 |1 is obsolete| | --- Comment #17 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 168107 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168107&action=edit Bug 37152: Aquisitions basket and OPAC suggestion deletion should use the op cud-delete Both deleting a basket in Aquisitions and deleting a suggestion in the OPAC take care of the confirmation in a javascript modal, rather than having a whole separate page for confirmation, so they should be using the op cud-delete rather than either cud-delete_confirm (which shouldn't ever be used) or delete_confirm (which they aren't doing, they already confirmed). Test plan: 1. There's no wrong behavior to see, so apply patch and restart_all 2. Aquisitions - Vendor search for My Vendor - Click My Basket 3. Click Delete basket, in the popup again Delete basket 4. Click Show baskets for vendor My Vendor and verify the basket is gone 5. OPAC - Your account - Purchase suggestions 6. Create a suggestion, then click the checkbox for it, Delete selected, confirm 7. Verify the suggestion was deleted Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> 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=37152 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |24.11.00 released in| | Status|Passed QA |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=37152 --- Comment #18 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 24.11! 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=37152 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Pushed to stable Version(s)|24.11.00 |24.11.00,24.05.02 released in| | CC| |lucas@bywatersolutions.com --- Comment #19 from Lucas Gass <lucas@bywatersolutions.com> --- Backported to 24.05.x for upcoming 24.05.02 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m Status|Pushed to stable |Needs documenting --- Comment #20 from Fridolin Somers <fridolin.somers@biblibre.com> --- Full CSRF not in 23.11.x -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com Text to go in the| |This fixes the delete release notes| |actions in these areas so | |that they now work as thye | |should: | | | |- Acquisitions: | | | | . Contracts - couldn't | |delete a contract (no | |confirmation message, | |didn't delete) | |(Acquisitions > search for | |a vendor > Contracts > | |Delete > Yes, delete | |contract) | | . Baskets - | |could still delete a basket | |(so no change in behavour), | |however it wasn't using the | |correct code to do this | |(Acquisitions > search for | |a vendor > select a basket | |> Delete basket) | | | |- MARC | |bibliographic frameworks | |and authority types: | |couldn't delete tags - the | |confirmation message didn't | |have the tag description, | |and didn't delete (there | |was no error message, it | |just didn't delete the tag) | |(Administration > Catalog > | |MARC bibliographic | |framework OR Authority | |types > Actions > MARC | |structure > [choose a tag] | |> Actions > Delete) | | | |- | |Patron categories: when | |attempting to delete a | |patron category that was | |still in use - it generated | |an error message, instead | |of a warning that it was | |still in use (and didn't | |delete the category) | |(Administration > Patron | |categories > Delete > | |[Warning that can't delete | |if in use OR Confirm | |deletion]) | | | |- Purchase | |suggestions in a patron's | |OPAC account: could still | |delete a purchase | |suggestion (so no change in | |behavour), however it | |wasn't using the correct | |code to do this (OPAC > | |Your account > Purchase | |suggestions > select | |suggestoon > Delete | |selected) | | | |(These fixes are | |related to the CSRF changes | |added in Koha 24.05 to | |improve form security.) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37161 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the|This fixes the delete |This fixes the delete release notes|actions in these areas so |actions in these areas so |that they now work as thye |that they now work as they |should: |should: | | |- Acquisitions: |- Acquisitions: | | | . Contracts - couldn't | . Contracts - couldn't |delete a contract (no |delete a contract (no |confirmation message, |confirmation message, |didn't delete) |didn't delete) |(Acquisitions > search for |(Acquisitions > search for |a vendor > Contracts > |a vendor > Contracts > |Delete > Yes, delete |Delete > Yes, delete |contract) |contract) | . Baskets - | . Baskets - |could still delete a basket |could still delete a basket |(so no change in behavour), |(so no change in behavour), |however it wasn't using the |however it wasn't using the |correct code to do this |correct code to do this |(Acquisitions > search for |(Acquisitions > search for |a vendor > select a basket |a vendor > select a basket |> Delete basket) |> Delete basket) | | |- MARC |- MARC |bibliographic frameworks |bibliographic frameworks |and authority types: |and authority types: |couldn't delete tags - the |couldn't delete tags - the |confirmation message didn't |confirmation message didn't |have the tag description, |have the tag description, |and didn't delete (there |and didn't delete (there |was no error message, it |was no error message, it |just didn't delete the tag) |just didn't delete the tag) |(Administration > Catalog > |(Administration > Catalog > |MARC bibliographic |MARC bibliographic |framework OR Authority |framework OR Authority |types > Actions > MARC |types > Actions > MARC |structure > [choose a tag] |structure > [choose a tag] |> Actions > Delete) |> Actions > Delete) | | |- |- |Patron categories: when |Patron categories: when |attempting to delete a |attempting to delete a |patron category that was |patron category that was |still in use - it generated |still in use - it generated |an error message, instead |an error message, instead |of a warning that it was |of a warning that it was |still in use (and didn't |still in use (and didn't |delete the category) |delete the category) |(Administration > Patron |(Administration > Patron |categories > Delete > |categories > Delete > |[Warning that can't delete |[Warning that can't delete |if in use OR Confirm |if in use OR Confirm |deletion]) |deletion]) | | |- Purchase |- Purchase |suggestions in a patron's |suggestions in a patron's |OPAC account: could still |OPAC account: could still |delete a purchase |delete a purchase |suggestion (so no change in |suggestion (so no change in |behavour), however it |behavour), however it |wasn't using the correct |wasn't using the correct |code to do this (OPAC > |code to do this (OPAC > |Your account > Purchase |Your account > Purchase |suggestions > select |suggestions > select |suggestoon > Delete |suggestoon > Delete |selected) |selected) | | |(These fixes are |(These fixes are |related to the CSRF changes |related to the CSRF changes |added in Koha 24.05 to |added in Koha 24.05 to |improve form security.) |improve form security.) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37163 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37162 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37152 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com Status|Needs documenting |RESOLVED Resolution|--- |FIXED --- Comment #21 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- This looks like a bug fix. Nothing to change/edit in the manual. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org