Bug 31031 - MarkLostItemsAsReturned does not work with batch item modification
Summary: MarkLostItemsAsReturned does not work with batch item modification
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: 21.11
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-23 16:21 UTC by Christopher Brannon
Modified: 2023-06-29 18:01 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2022-06-23 16:21:10 UTC
If you choose the "from the batch item modification tool" in the MarkLostItemsAsReturned preference, it does not work.  Status is changed as usual, but it does not check the item(s) in.

This means for now, staff have to do this manually, one item at a time!
Comment 1 Christopher Brannon 2022-06-23 16:56:40 UTC
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.
Comment 2 Sara Brown 2022-06-23 17:40:24 UTC
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
Comment 3 Christopher Brannon 2022-06-23 18:54:47 UTC
(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.
Comment 4 Christopher Brannon 2022-10-06 23:28:00 UTC
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.
Comment 5 Nick Clemens 2022-10-27 13:25:58 UTC
(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
Comment 6 Christopher Brannon 2023-02-14 00:19:37 UTC
(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.
Comment 7 Jason Robb 2023-06-29 18:01:18 UTC
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.