https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33446
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from [email protected] --- Going the "other direction" would be useful as well. If I check in a book and trap a hold (putting the item in transit), but then subsequently realize that the book is too damanged it's two parts to "fix" the hold. 1) Mark item as damaged 2) check in item : This comes up with the "item is in transit for a hold" modal. You have the option to cancel the transfer. 3) The hold has been changed to an item level hold and the hold status at this point is STILL "being transferred" to Sparta. Checking in the item and canceling the transfer should automatically update the related hold. The modal doesn't have any information about WHIcH hold the transfer is for, so the staff have no way to quickly go to the patron record and revert the hold. My test example was easy because there was only 1 hold on the biblio, but this would be a tedious task if you have lots of items and holds to wade though. In our organization, adding a second step from the patron (or biblio) revert hold screen is sub-optimal so I would want that to be optional, if offered. You have many reasons you might revert a hold which may or may not affect the item's transit status. However, taking an item OUT of transit will ALWAYS affect the related hold. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ 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/
