Deleting items with checked out status?

[[e-mail]]

Evergreen allows items with checked out status to be deleted (with prompt for confirmation). After the deletion the circulation record is still open. The item can not be checked in on Check In screen, due to "Item not found".

Thinking of the library workflow, this could cause much confusion. On one hand an item shown up in the bookdrop can not be checked in or found in the catalogue. On the other hand returned items are not cleared from patron accounts, as the item can only be checked in from the patron account.

So we need some enhancement. Two options may be considered:

1. give libraries the option of blocking deleting items with checked out status
2. close the circulation record when a checked out item is deleted

These options may be on the Library Settings Editor, so individual library can make their own choice.

[Jason Etheridge (phasefx)]

> 1. give libraries the option of blocking deleting items with checked out status
> 2. close the circulation record when a checked out item is deleted

This even more fun if the item barcode gets re-used for a different item.

Check-In from the patron Items Out interface also fails to work with
deleted items, since the underlying API makes use of item barcode
instead of a circ or item id, so that's another thing to consider,
more API support.

[Galen Charlton (gmc)]

> 1. give libraries the option of blocking deleting items with checked out status
> 2. close the circulation record when a checked out item is deleted

I think that the default behavior should be to block the deletion in this case - in no event should there be an open circulation on a deleted item. Any options supplied should be concerned with whether to allow an operator to override and and mark the loan as returned before deleting the item. There is an edge case to consider. If a cataloger has an item in hand to weed and delete that is still marked as out on loan, a library may want to waive all overdue fines as (apparently) the item was not properly marked as returned in Evergreen.

[[e-mail] (tji)]

>Check-In from the patron Items Out interface also fails to work with
>deleted items, since the underlying API makes use of item barcode
>instead of a circ or item id, so that's another thing to consider,
>more API support.

CheckIn on Items Out screen works (tested on 1.6.0.2). This helps us solve the issue without going to db to close the circs.

I agree with Galen. Blocking deletion should be the default behaviour. Considering the workflow in the big libraries, permission controlled deletion can be allowed. But the outstanding transactions should be taken care of.

[Jason Etheridge (phasefx)]

> CheckIn  on Items Out screen works (tested on 1.6.0.2). This helps us
> solve the issue without going to db to close the circs.

This should not work currently. :( Is it possible that the item
barcode was re-used and you accidentally checked in a different
circulation involving the new item?

> I agree with Galen. Blocking deletion should be the default behaviour.

I'm in favor of this.

[[e-mail] (tji)]

>> CheckIn on Items Out screen works

>This should not work currently. :( Is it possible that the item
>barcode was re-used and you accidentally checked in a different
>circulation involving the new item?

This does work. My latest test was done this morning with a dummy item. Before I checked it in on Item Out, I searched for the item on F5. I got a Not Catalogued prompt.

[Jason Etheridge (phasefx)]

> This does work. My latest test was done this morning with a dummy item.
> Before I checked it in on Item Out, I searched for the item on F5. I got
> a Not Catalogued prompt.

Ah, it looks like at some point we did augment the API to accept copy
id's in addition to barcodes. I just don't remember doing it. Ignore
me. :)

[Michael Peters (mrpeters)]

I was giving some thought to this today and decided to try deleting a copy via the database that still had an open circ.

To my surprise, it was successful in marking the item deleted = true (following the "protect_copy_delete" rule, of course). I think this is what then frees up the barcode for use elsewhere, like the situation Jason presented.

Would a new rule on asset.copy, preventing you from marking an item "deleted = true" when it's referenced by an action.circulation row that is unclosed appropriately resolve this?