FYI, what we expect with the batch item modification is the same behavior we get if we change the lost status on an individual item in the items tab.  With this setting set, we can change the lost status of the item, and the item is checked in, but the item charge is left on the patron account.  This is ultimately what we want so that we can delete the item without removing the charge.  We do this for long lost items that we need to get out of the system, but still want the patron to pay for.

Currently, with just that setting set, it changes the status, but doesn't check the item in.

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

(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.

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.

(In reply to Christopher Brannon from comment #4)
> 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.

Can you supply any details on this? Confirming Sara's comment, batch modification has not marked an item returned unless it was previously not lost for as far back as I can tell.

If batch modification does return the item, it uses MarkIssueReturned - which should never generate a credit

(In reply to Nick Clemens from comment #5)
> (In reply to Christopher Brannon from comment #4)
> > 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.
> 
> Can you supply any details on this? Confirming Sara's comment, batch
> modification has not marked an item returned unless it was previously not
> lost for as far back as I can tell.
> 
> If batch modification does return the item, it uses MarkIssueReturned -
> which should never generate a credit

Unfortunately, no.  This fell off my radar for a while.  I will update if we see any more.

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.