need for a "show deleted items" feature within the staff client

[Chris Sharp]

We get many issues reported to the PINES helpdesk where the front end staff are at a loss to explain some of the behavior of their items. The usual complaint is that an item has "fallen out of Evergreen" (or similar wording). Invariably, a direct SQL query reveals that the item was manually deleted by a staff member, but, aside from reports, which are not usually directly accessible to frontline staff, there is not a way for them to see for themselves when/by whom an item was deleted.

One suggestion might be a "show deleted items" checkbox option (defaulting to off and *not* persistent once set) in the Item Status interface so that a barcode scan would show all items, deleted or not. This option would probably require that "Is Deleted" be a default column added to the display.

The bottom line is that we're seeing multiple use cases where circulation staff need to be able to track the fate of deleted items to explain what is otherwise unexplainable.

Evergreen 2.5.1
OpenSRF 2.2
Ubuntu 12.04 LTS
PostgreSQL 9.3

[Michele Morgan (mmorgan)]

Just to add to this, if an item is checked out at the time it's deleted (which is possible if a staff user has the COPY_DELETE_WARNING.override permission), the deleted item will show on the patron's record, but no where else in the client. This means if the item is returned without the patron present, there's no way to check it in via the checkin screen. The item can be checked in from the patron record, but staff users have no way of viewing the item to find the patron that has it checked out.

A checkin modifier to check for deleted items at checkin would make it possible to check these items in. A checkbox on the item status screen, to include deleted items would allow staff users to view the item. Ideally, staff users should also have the ability to undelete an item when appropriate.

[Jessica Woolford (jwoolford)]

+1 to Michele's comments regarding checking in deleted items. We took away the permission for staff to do this a long time ago because of all the problems it gave us, but library staff would really like to be able to delete their items that have been in the lost status for a long time. This just came up recently, hence this comment on an old bug report. Giving them the ability to check in deleted items from the interface where checkin occurs would allow us to give them the permission back.

[Tiffany Little (tslittle)]

Since this is a wishlist bug, my additional wishlists for this feature would be:

1. A "deleted by" and "deleted on" [date] columns.

2. If deleted items could have a different styling in lists, say that they have red text or something. Just something to make them stand out in a list of barcodes. Yes, "Is Deleted?" should be available, but if you have a list of 100+ barcodes it could be very easy to not notice one deleted one. And I would say generally people tend to work in larger lists of barcodes than they would in lists of bib records, so overlooking one deleted one is totally possible.

[Jane Sandberg (sandbergja)]

One note: right now, the XUL and Angularjs clients behave the same way when a user enters a deleted barcode into item status as when they enter a completely invalid barcode: it just gives the message "was either mis-scanned or not cataloged".

If this proposal moves forward (or maybe even if not), this message should probably be more specific when the user enters a deleted barcode. Note that this would require changing the underlying pcrud call in the item service.

[Elizabeth Davis (elidavis)]

Not sure how everyone feels about this but it would be nice to be able to have an undelete button for items like we do for bib records.

[Jennifer Pringle (jpringle-u)]

Something to consider (which I don't know the answer to) is how Evergreen would handle deleted items where the barcode has been re-used for another item.

I suspect some of the instances we have of this are due to lost items being deleted and then re-catalogued when they reappear which would be resolved by giving staff a way to undelete an item, as Elizabeth suggests.

[Elizabeth Davis (elidavis)]

+1 to Jennifer's comment. From a support standpoint, this happens often. We also have instances of staff deleting things that are not in an 'ideal status' for deletion. We then have to get it undeleted so they can make the adjustments and delete again.