Transfer item to previously marked destination fails to transfer

Bug #1897321 reported by Mary Llewellyn on 2020-09-25
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

Evergreen 3.5

Steps followed

1. Target bib record marked for holdings transfer
2. Item in Holdings View on original record is selected for Action/Transfer Items to Previously Marked Destination

Expected reaction:
That the item would would disappear from Holdings View on the original record and would be transferred to the marked bib record. This is the behavior in Evergreen 3.1

What happened:
In angular holdings view: A box appears with error message "Please select a suitable transfer target."
In traditional holdings view: first time attempting transfer, no response from the system. Second attempt: green box appears reporting "Item(s) transfered" but the item does not transfer.

Screen images attached.

Mary Llewellyn (mllewell) wrote :
Bill Erickson (berick) wrote :

Hi Mary, in the Angular client, "Transfer Items ..." requires a call number be marked as the destination. "Transfer Holdings ..." requires a bib record to be marked as the destination.

Mary Llewellyn (mllewell) wrote :

Hi Bill,

What about in the traditional client? The steps I used in 3.1 no longer work in 3.5.

Mary Llewellyn (mllewell) wrote :

Hi again, Bill. I tried Transfer holdings in the Angular client just now, and nothing moved. At least I didn't get the message I mentioned before.

Bill Erickson (berick) wrote :

There must be something up with version 3.5 specifically. In master, both types of transfers work as expected for me in both Angular and traditional catalogs.

Hoping someone with a 3.5 system can verify.

Andrea Neiman (aneiman) wrote :

3.5.0 test system, can confirm what Mary sees with Transfer Holdings in the Angular client.

1) Marked a record as Holdings Destination
2) Opened a new record; double checked that "Mark For..." showed the expected bib ID for Holdings Destination
3) Attempted the "Transfer Holdings to Marked Destination" action
4) The screen refreshed but the Holdings did not transfer. There was no console error.

However, I am able to transfer holdings just fine on this 3.5 system using the 'old' staff catalog and the above steps.

Mary Llewellyn (mllewell) wrote :

So it sounds like the way it works in 3.1 where selecting Transfer item... and my item, call number and all gets moved to the bib record was a bug?

Andrea, I'm able to transfer the holdings in the old catalog (now that I've readjusted my expectations.

Elaine Hardy (ehardy) wrote :

In case it helps, in 3.4, the bug is there as well.

 If I mark a record as transfer destination that does not have a holding for my library and then do an item transfer, the call number and item transfer. (if the item to be transferred is one of several copies, just that item is transferred and a new call number is created on the destination record)

If I mark a library as the transfer destination, with no holding for my library, I can also transfer the call number and item using item transfer.

So, far, I like this and don't consider it a bug -- that old saying -- it isn't a bug, it's a feature!

But, if I have holdings on a library and mark the record as destination, then transfer an item with different call number to that record as an item, the call number and item transfer. Which would be a bug if I didn't want a separate call number on the destination record. I would prefer the transfer to fail and tell me why or ask if I wanted to continue in case I did want to create a new vol/call number on a record.

I think we need to do more testing to see if this is a bug or how we want it to function. There are other scenarios to see what happens. Basically, I feel like an item transfer should transfer just the item and fail if there is not a call number on the destination record to keep the distinction. At the same time it is really convenient not to need to create an empty call number on the destination record.

I will try to send this to the cat list today for everyone to test to see whether we should open a bug report and how we would define the bug.

Mary Llewellyn (mllewell) wrote :

> If I mark a record as transfer destination that does not have a holding for my library and then do an item transfer, the call number and item transfer. (if the item to be transferred is one of several copies, just that item is transferred and a new call number is created on the destination record)<

That's what I was experiencing in 3.1 and was looking for in 3.5.

>If I mark a library as the transfer destination, with no holding for my library, I can also transfer the call number and item using item transfer.

So, far, I like this and don't consider it a bug -- that old saying -- it isn't a bug, it's a feature!<

What I liked was that I no longer had to mark a library.

>But, if I have holdings on a library and mark the record as destination, then transfer an item with different call number to that record as an item, the call number and item transfer. Which would be a bug if I didn't want a separate call number on the destination record. I would prefer the transfer to fail and tell me why or ask if I wanted to continue in case I did want to create a new vol/call number on a record.<

But if I did want a different call number, I like this behavior. I wouldn't want the system to assume that everything should be folded into one call number. Asking if we wanted a new call number on the destination record in that case would be a fair compromise.

I've been enjoying not having to fiddle in Holdings View and marking libraries and/or call numbers as destinations. Since we manage things centrally, if I find a number of libraries are on the wrong record, being able to move all the copies at once without regard to library, and having them end up on the correct libraries with their original call numbers in one step has been ideal.
In fact, since the item transfer worked this way, it made me wonder what the volume/call number transfer was for. If I wanted to move multiple items with the same call number, all I had to do was mark the items in Holdings View. And not having to create empty call numbers for targets was great! It made the transfer process so simple.

I look forward to this conversation on the catalogers' list.

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

Other bug subscribers