[Evergreen-catalogers] Fwd: Omnibus cataloging bug fixes and transferring items

Tue Aug 7 16:00:56 EDT 2018

Hi Andrea,

By George I think I've got it! Let's see if I walked my way through this
successfully.

In Item Status you are transferring items so the choice is to marked volume
or to marked library. Item status lines are the equivalent of the barcode
"line" in xul holdings maintenance.
Thus you cannot transfer an item (i.e. barcode no volume) to a bib record
from item status. You can only do that in holdings view.

In holdings view in the web client the volume line and the barcode line in
xul holdings maintenance have been merged into one.
In holdings view it appears the simplification of the transfer choices is
because of what's marked as the destination; a volume (and any attached
item) can go to a record or library and an item can go to a record or
volume.

I find this a little confusing as transferring volumes to a bib record
moves volume+item and transferring items does the same thing, it also moves
the volume. I can see the need to transfer an item to a marked volume
separating it from its original volume and moving it to another, but if
it's the record that's marked there is no distinction.

Kathy Lussier has opened a discussion on the bug on the item/copy
terminology so I'll comment there on that topic.

Janet

Janet Schrader

Bibliographic Services Supervisor | CW MARS

67 Millbrook Street, Suite 201, Worcester, MA 01606

P: 508-755-3323 x 325 | F: 508-757-7801

------------------------------

jschrader at cwmars.org  ||  http;//cwmars.org <http://www.cwmars.org/>

On Wed, Aug 1, 2018 at 9:25 AM, Andrea Buntz Neiman <
abneiman at equinoxinitiative.org> wrote:

> Hi Janet,
>
> The copy/item labeling inconsistency goes back a while -- see the
> discussion on this LP ticket: https://bugs.launchpad
> .net/evergreen/+bug/1538691, and I recall that XUL had similar issues as
> well.  As far as I can tell (though someone please correct if I'm wrong!)
> they can be considered synonymous, just not used consistently.
>
> As you noted the patch in cataloging omnibus didn't change options in Item
> Status.  I'll look into this as it might've been an oversight.
>
> The reduction in choices from holdings view was intended to clarify &
> simplify the options, since there was a lot of feedback that this was
> confusing and clunky.  If you've identified a use case for restoring one of
> the options, or a way in which the process can be even further improved,
> please file a follow up bug!  For the use case you mention, if I understand
> you correctly,
> you should be able to mark the volume on the other record as a transfer
> destination and then move the item -- this should update the volume (call
> number) info but keep the library info the same.  If you notice this is not
> the case, that would be another situation that would warrant a follow up
> bug.
>
> Thanks for your testing & feedback.
>
> Andrea
>
> On Tue, Jul 31, 2018 at 5:55 PM Janet Schrader <jschrader at cwmars.org>
> wrote:
>
>> I forgot to say that the test server is release 3.0.10. Our production
>> server is 3.0.9.
>>
>>
>> Janet
>>
>>
>> ---------- Forwarded message ----------
>> From: Janet Schrader <jschrader at cwmars.org>
>> Date: Tue, Jul 31, 2018 at 4:59 PM
>> Subject: Omnibus cataloging bug fixes and transferring items
>> To: Evergreen Community Catalogers <evergreen-catalogers at list.eve
>> rgreen-ils.org>
>>
>>
>> Hi All,
>>
>> Before getting into my transfer question I'd like to know if the "add
>> volumes" button will from now on by labeled "add copies". The copy/item
>> inconsistency is frustrating, and may come into play with the transfer
>> options as shown below.
>>
>> Today Jason put the patch for the omnibus cataloging bug fix on a test
>> server so I could test it with my own data. Empty libraries are now
>> visible. I'm able to add a volume/item to an empty library. I can add a
>> volume (no item) to an empty library. I am testing transferring items now
>> and am curious about what happened to the choices that were there before
>> the bug fix was added. Is this just my installation or is it part of the
>> fix?
>>
>> In item status the choices are the same both before and after the fix was
>> added and there are only two.
>>
>>
>> In holdings view the choices are different from item status. Can someone
>> explain why one choice is to transfer copies and one to transfer items?  Does
>> it have to do with copies meaning volume/item and item only the barcoded
>> item?
>> In the 3.0.9 client I have this, lots of choices.
>>
>> On my test server with the bug fix I have this, only two choices.
>>
>>
>> The mark for transfer choices are also different with the bug fix.
>> In our 3.0.9 version
>>
>>
>> With the bug fix the two choices are combined. Why? There could be a time
>> when a library wants to transfer an item to their library on a different
>> record where there is already a volume that's different.
>> Server with bug fix.
>>
>>
>>
>> Onward and upward!
>>
>> Janet
>>
>>
>> Janet Schrader
>>
>> Bibliographic Services Supervisor | CW MARS
>>
>> 67 Millbrook Street, Suite 201, Worcester, MA 01606
>>
>> P: 508-755-3323 x 325 | F: 508-757-7801
>>
>> ------------------------------
>>
>> jschrader at cwmars.org  ||  http;//cwmars.org <http://www.cwmars.org/>
>>
>>
>> _______________________________________________
>> Evergreen-catalogers mailing list
>> Evergreen-catalogers at list.evergreen-ils.org
>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/everg
>> reen-catalogers
>>
>
>
> --
> Andrea Buntz Neiman
> Project Manager for Software Development
> Equinox Open Library Initiative
> abneiman at equinoxinitiative.org
> 1-877-OPEN-ILS (673-6457)
> *www.equinoxinitiative.org <http://www.equinoxinitiative.org>*
>
> _______________________________________________
> Evergreen-catalogers mailing list
> Evergreen-catalogers at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/everg
> reen-catalogers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-catalogers/attachments/20180807/ada2e76a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 7769 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-catalogers/attachments/20180807/ada2e76a/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 8986 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-catalogers/attachments/20180807/ada2e76a/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 18976 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-catalogers/attachments/20180807/ada2e76a/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 10456 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-catalogers/attachments/20180807/ada2e76a/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13836 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-catalogers/attachments/20180807/ada2e76a/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 14915 bytes
Desc: not available
URL: <http://list.evergreen-ils.org/pipermail/evergreen-catalogers/attachments/20180807/ada2e76a/attachment-0011.png>