https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8132
--- Comment #40 from Jonathan Druart <[email protected]> --- (In reply to Kelly McElligott from comment #39) > Jonathan, > Two issues that I have with this: > > In this step: > > 2/ Select them and confirm the deletion > => Nothing happened and you get a message saying that one of the 2 items > from B2 is blocking the whole deletion process > > This does block the whole process! So all the item that could be deleted - > don't get deleted, the button to return to Batch Item Deletion, results in > having to re-enter all the items that could have been deleted but weren't > because of 1 item. Could the return to deletion button bring back the > screen prior to this. This is just a lot of extra work. I will see what I can do. But yes, I do expect the whole process to be blocked. If something is wrong, the whole transaction is rolled back. > In this step: > 3/ Remove the biblio-level hold > 4/ Repeat 1 > => The deletion has been effective! > > Koha is deleting both items on Bib4 - one of which had an item level hold > (not triggered). The hold does not get orphaned, because it too is deleted. > Is this what you would like to see happen, a library can delete an item with > an item level hold if it isn't triggered? It is how it works so far. That's why I added a note in the commit message about this behavior. The hold has to be found (waiting or in transfer) to see the deletion blocked. I guess it's how it works as well in the cataloguing module. It's not a behavior's change I want to introduce with this patchset, if we decide to modify it we should do it on its own bug report. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
