Reset Copy Location

Bug #1276874 reported by Holly Brennan
46
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Evergreen
Triaged
Wishlist
Unassigned

Bug Description

Goal: To make temporary copy/shelving location changes just as easy to undo as they are to batch edit the first time around.

The ideal use for this would be to utilize a copy location such as DISPLAY.

For example, I just pulled items from various areas in our library for a display on Fossils. These items came from 7 different locations. I added them all to a copy bucket, batch edited the location to Display, and voila - all the items now have the shelving location of Display.

It is much less fun to return items to their original shelving locations. It probably wouldn't save much time to group the items into tiny groups based on their former/original locations and batch edit 3-4 items at one time, and mistakes could easily be made. The safest (and least fun) method would be to pick up each item and edit the location based on where it should go.

Wouldn't it be more fun, and extremely easy, if we could make use of that copy bucket I made in the beginning? It could be as simple as returning to my Fossil display copy bucket, and clicking a button that reset the copy location of each item to its previous location. Whether it was called Undo, Reset, or MAGIC - it would be awesome.

Based on some feedback on the general email list, this wish seems possible and would be a welcome addition to future versions. I am running 2.3.4, but it doesn't seem like anything exists yet (and 2.5.2 is the most current released version as of today, while 2.6 is very close).

FROM CONVERSATIONS ON EVERGREEN GENERAL MAILING LIST:

Dan Scott:
Yep, dreamed of it long ago for a slightly different context: putting items on reserve (which could change their location and call number, too).
One possibility that now leaps to mind is to make use of the auditor tables that track every change to a given copy and call number (and many other entities in the database... at least until those auditor tables are purged). We could whip up a batch action along the lines of "Reset copy location to previous location" pretty easily, I think.

Jim Taylor:
Entirely possible…I believe Symphony can do that so already have an example. One thing they didn’t account for, at the time anyway, was what happens if you change an item after that. Say you decide to pull it from Fossils and put it in “Really Old Guys” instead. What happens? Surprisingly, everybody in the group discussion at a conference seemed to think I was silly for even being concerned even though they admitted it might be a problem. Just something, seemingly obvious, but , apparently not, to take into account if you pursue development of such a feature.

Sarah Childs:
On a related note, in Indiana we recently added "Display" as a status.
This works great for displays that you just fill up with new things as the previous ones get checked out. Instead of changing the shelving location you set the status of the materials as display, and then when they get checked out and checked back in they just go back through the regular reshelving to available status cycle and get reshelved at their usual shelving locations. Obviously, this isn't so useful for long term displays where you want the items on display to return to the display after being checked out.

Ben Shum (bshum)
Changed in evergreen:
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Jason Stephenson (jstephenson) wrote :

At MVLC, we would do this with a table in a local schema (mvlc.temp_copy_changes, or similar). We'd record the copy id, what changed, the old and new values. Then, we could later run a script to set them back to the regular copy location. It was more generic than that and could be used for status and some other fields as well. This required central site intervention since library staff can't run SQL queries in the database.

I think having a feature like this would be very handy. How that would be implemented, I'm less sure of at the moment.

It could be done more or less with copy buckets. If you are mixing items from different locations, the safest thing would be to make a bucket for each origin copy location and maybe put that location's name in the bucket name as a reminder. Still not as convenient as what the bug description desires.

Andrea Neiman (aneiman)
tags: added: copylocations
removed: copy location
Andrea Neiman (aneiman)
tags: added: itemlocations
removed: copylocations
Revision history for this message
Millissa (millissam) wrote :

Found this post and the suggestion from Sarah Childs at Indiana to change the "status" instead of the "shelving location" was just what we were looking for. Thank you for the suggestion!

Revision history for this message
Millissa (millissam) wrote :

Ran into a small roadblock with using "Display" as the status. Items with holds that are on this status don't show up on the pull list for our assistants. We are currently just making the display items unholdable but would love a way to make the pull list see the items with a display status.

tags: added: cat-locations
removed: itemlocations wishlist
Elaine Hardy (ehardy)
tags: added: buckets-item
removed: buckets
Revision history for this message
Benjamin Kalish (bkalish) wrote :

Ideally it would be easy to reset any item to it's previous shelving location regardless of whether or not it had originally been changed as part of a batch edit. We often remove just *some* items from a display.

Revision history for this message
Elaine Hardy (ehardy) wrote :

If the shelving location **change** could be temporary (similar to alerts), and either have a set time for it to be in Display, and/or that it could be changed by having a "return to permanent/previous shelving location" option in the actions menus.

Revision history for this message
Ruth Frasur Davis (redavis) wrote :

I'm glad to see that buckets are listed here. This seems like it would be most appropriate to have as an a saved bucket session. And would require that batch edits be available in the same way that they are for user buckets and record buckets and would ideally include the naming of sessions like in user buckets to allow for rolling back.

But, as mentioned by Elaine in #5, there are some other possibilities.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.