Evergreen needs volume buckets
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
Evergreen current has copy buckets and record buckets to allow end-users (catalogers) to perform batch changes on multiple objects at once. Missing from this is volume buckets, which would allow catalogers to batch-edit volumes in the same manner.
Example use case:
A PINES cataloger identifies 75 items with call number labels that need to be changed. The format of the call number labels is (for example):
CDMUSIC MUSICALS WEBBER
The cataloger wants to change MUSICALS to MUSICAL to correct a newbie cataloger labeling mistake.
Currently she would need to export a list of item barcodes, import them into the Item Status screen, select a few at a time, then go to Actions for Catalogers -> Edit Volumes and manually edit each barcode.
A volume buckets feature would allow the cataloger to select the items from that same list, add them to a volume bucket, and perform a "find and replace" function on each volumes barcode in a batch, increasing efficiency and productivity.
I encourage others to offer additional use cases for this feature too.
Our current version:
Evergreen 2.3.6
OpenSRF 2.1.2
PostgreSQL 9.1.9
Ubuntu 12.04 LTS
tags: | added: cataloging |
tags: | added: buckets |
Changed in evergreen: | |
status: | New → Confirmed |
tags: |
added: buckets-volume removed: buckets |
Having experienced this "workflow" many, MANY times (sad, I know), I'd love to see this as a bucket function. As far as use cases go, when separating out specific collections from another, we often need to change a large number of call numbers in the system to reflect the new collection. We've also had some inconsistent labeling over the years throughout the collections which makes collection report output nearly unusable without a lot of intervention. Fixing all these call numbers in EG has taken hundreds of hours because of the volume of variants. Our library did experience a pretty large amount of database neglect over the years, but I can't imagine that we're particularly unique from other small libraries (maybe even some larger libraries).