Reset Copy Location
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.
Changed in evergreen: | |
importance: | Undecided → Wishlist |
status: | New → Triaged |
tags: |
added: copylocations removed: copy location |
tags: |
added: itemlocations removed: copylocations |
tags: |
added: cat-locations removed: itemlocations wishlist |
tags: |
added: buckets-item removed: buckets |
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.