https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31031 Sara Brown <sbrown@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrown@bywatersolutions.com --- Comment #2 from Sara Brown <sbrown@bywatersolutions.com> --- In my testing, it depends on the lost status prior to the batch modification: -If I add a lost status via batch item modification on an item that is checked out but not currently lost, it *does* check the item in -If I run batch item modification on a lost item that is still checked out to change it to a different lost status, it *doesn't* check the item in -- 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=31031 --- Comment #3 from Christopher Brannon <cbrannon@cdalibrary.org> --- (In reply to Sara Brown from comment #2)

In my testing, it depends on the lost status prior to the batch modification:

-If I add a lost status via batch item modification on an item that is checked out but not currently lost, it *does* check the item in -If I run batch item modification on a lost item that is still checked out to change it to a different lost status, it *doesn't* check the item in

Yes. This is contrary to how the feature works on the item tab. We take advantage of the behavior (how it works on the item tab) so we can leave the charge but check the item in so it can be deleted. Doing this in the batch tool would make this process easier. However, the batch tool isn't working the same way. AND, if there is a way to delete items without removing the charge that is less complicated, I welcome that. But for now, this is what we have to do to retain that charge. -- 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=31031 --- Comment #4 from Christopher Brannon <cbrannon@cdalibrary.org> --- FYI, we just ran into another inconsistency with this setting and batch modification. We had an item actually get checked in, but it also credited the charge. It's behavior seems to be VERY inconsistent. -- 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=31031 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=32019 -- 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=31031 Jason Robb <jrobb@sekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrobb@sekls.org --- Comment #7 from Jason Robb <jrobb@sekls.org> --- Our workflow involves marking items "Long overdue (lost)" with the cron, but leaving the item checked out so staff can evaluate and make the final call on charging the item to the account by then marking it "Lost and charged". We typically do this from the items tab which is a single step. Using batch item modification, it requires the removal of the first lost status in one job, then the application of the new lost status in a second job to force the charge/checkin action. If it can work in one step in one place, it makes a two-step process in other places seem clunky. It'd be awesome if instead of tying how this works to what page you're on, it is tied to what status you are applying. Bug #22780 touches on that idea. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.