Deleted shelving locations listed when running reports

[Blake GH]

It's not useful to have deleted shelving locations listed in a list of available shelves when running reports. In order to replicate this, you will have to design a report that has a shelving location filter set to "in list".

It's not possible to delete a shelf in the first place if there are items on it, therefore, listing deleted shelves should yield 0 results. They are clutter on the UI.

[Anna Goben (agoben)]

You can delete a shelving location that has deleted holdings still attached, so we do still regularly return data on deleted shelving locations (circ stats primarily). If the SLs are going to be fully purged, then we'll need a way to dump those holdings to another reportable location as part of the SL deletion process.

[Robert J Jackson (rjackson-deactivatedaccount)]

Would it be possible to modify definition(s) used by reporting to allow for filtering out deleted shelving locations from the "in list" values displayed? This way staff could select to allow deleted locations if they needed to find material that had been deleted in the past, or, only show items/locations that are not deleted.

[Ruth Frasur Davis (redavis)]

This is an ongoing issue that continues to cause consternation among our end users, especially when shelving location projects involve multiple branches and were perhaps not planned out with full consideration of consequences or completed. Because these shelving locations do not show up in the editor any longer, it confuses staff who don't know where they showed up from or what to do with them.

[Tiffany Little (tslittle)]

Acq runs into this too--if you're looking for Fund ID (in list), you'll get a list of all funds that have ever existed. That becomes especially hard because funds tend to replicate codes each year with only the fund year as a distinction, but only code is returned in the list, so you'll get 4 instances of "Adult"--which one is the right one?

Having said that, I think deleted shelving locations *should* still show up in the "in list" filter. You should be able to run reports on them; it's data in the database and you should be able to pull it out in reports. I don't necessarily think you need to throw it somewhere else, either, you should be able to find it in its original spot.

So in Acq dropdowns in Angular, now we've got where the dropdowns are populated by code (like always), but it's also now populated by year and ordering agency automatically. So it looks like Adult (SYS-1) (2023). Using that as a springboard, my suggestion--particularly once reports is Angularized--is that if:

1. The Filter is "in list" type.
2. There is a "deleted" field on the table
3. That row is deleted=true

That it should display in the "in list" as (Deleted), e.g. "Adult Fiction (Deleted)".

I get that it's still visually cluttery, but it's at least clearer what you're selecting. And it makes sense to not see them in the UI for day-to-day work, but the reporter is for data and the data should be available to be pulled.

[Elizabeth Davis (elidavis)]

It is also seen in the Simple Reporter.