[OPEN-ILS-GENERAL] Problem with Edit Items / Volumes per Bib function?

[Michele Morgan]

Hi Jennifer,

I wonder if you are also running into a related bug:

https://bugs.launchpad.net/evergreen/+bug/1253732

>From your original description, a new call number is being created, but
your item isn't being transferred. If the Edit Items / Volumes per Bib is
working the way it should, then the fact that a new Volume is being created
should be invisible to the staff member making the edit.

You shouldn't be ending up with empty call numbers unless there's something
else going on.

BTW, no one's confirmed this bug yet, so if it is what you're seeing, you
can mark it as confirmed.

Hope this helps,
Michele

--
Michele M. Morgan, Technical Assistant
North of Boston Library Exchange, Danvers Massachusetts
mmorgan at noblenet.org


On Thu, Jul 23, 2015 at 4:40 PM, Walz, Jennifer <jlwalz at asbury.edu> wrote:

> All -
>
>  Here is where I don't understand the current construct and wouldn't it
> make more sense to have the call number and the barcode be at the item
> level for each record?
>
>   Like this:
>
> Title blah blah blah etc, author and owning library and so on.
>   -   345.0998 B58a   1908987293
>   -   345.0998 B58a   1908987294
>   -   345.0998 B58a   1908987294
>
> Why do the call numbers need to have their own level called volume?  What
> does it add to the mix?   In other words, what does this particular
> construct enable libraries to do specifically?
>
>  If you had the call number at the same level of the barcode, you could
> STILL update either and not affect the owner or copy location (unless you
> wanted to).   Let's say an owning library had 5 copies of a title, but
> wanted to put them in five different locations - each with a different call
> number.   You could if you wanted, without creating and fiddling with
> "volume" level data.   Why can't that level just be eliminated altogether?
>
>  Just saying.   I'm just not seeing the benefit of having the call number
> / volume level.   Seems to complicate matters unnecessarily.
>
>  If anyone can give me ANY help to fix about 300 records that have gotten
> deleted and then mysteriously not, I would be most grateful!   Where is
> that pesky "deleted" indicator anyway??   I want to turn it "off" for these
> records. (my other pet peeve!   Items should be GONE from the system
> entirely and not in a phantom zone!)
>
> Thanks!
>
> Jennifer
> --------------------------------------------------
> Jennifer Walz, MLS - Head of Research & Distance Services
> Kinlaw Library -  Asbury University
> One Macklem Drive, Wilmore, KY 40390
> 859-858-3511 ext. 2269
> jlwalz at asbury.edu
>
>
> -----Original Message-----
> From: Open-ils-general [mailto:
> open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Kathy
> Lussier
> Sent: Thursday, July 23, 2015 4:29 PM
> To: open-ils-general at list.georgialibraries.org
> Subject: Re: [OPEN-ILS-GENERAL] Problem with Edit Items / Volumes per Bib
> function?
>
> Hi Jason,
>
> Yes, I understand the mindset behind the current behavior. If I were to
> look at tackling this bug/wishlist request, I think I would look at adding
> a prompt that appears when the user is updating a volume from the unified
> editor if there are other copies attached to the volume that aren't being
> edited at the time the update is being made.
>
> In many cases, I think the answer to the question is Yes, but I can see
> why you wouldn't want to change the call number label for all six copies if
> the intent was just to update the label for one.
>
> Kathy
>
> On 07/23/2015 04:22 PM, Jason Etheridge wrote:
> > Should we expect for all copies on a volume to inherit a call number
> > "tweak" if just a single copy was being edited as the entry point?  An
> > answer of No went into the mindset that built the current behavior.
> >
>
> --
> Kathy Lussier
> Project Coordinator
> Massachusetts Library Network Cooperative
> (508) 343-0128
> klussier at masslnc.org
> Twitter: http://www.twitter.com/kmlussier
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20150724/0fb4ea52/attachment.html>