Transfer item to previously marked destination fails to transfer

[Mary Llewellyn]

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.

[Bill Erickson (berick)]

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)]

Hi Bill,

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

[Mary Llewellyn (mllewell)]

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)]

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)]

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)]

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)]

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)]

> 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.

[William C. Szwagiel (wszwagiel)]

Evergreen Version 3.11.1

I am not entirely certain if this is the same situation as described in this report thus far (and if it is not, I apologize for bumping such an old thread and not creating a new bug report), but I was doing some item transfer tests after receiving a report of some issues that a member library was encountering when attempting to transfer an item from one record to another.

First, when marking a Call Number as a transfer destination, there does not appear to be any way to tell that it has been successfully marked like there is when you mark a record for a Holding Transfer. Or if there is, I have not been able to locate it.

Second, based on my understanding of transferring items works, you have to select the Call Number line in the Holdings View, not the Item line, and mark it as the transfer destination. However, when the member library in question accidentally selected the Item line and tried to transfer another item to it, they reported that, while the item did not actually transfer, they still received the green "Item Has Been Successfully Transferred" notification.

When I attempted to replicate this behavior, nothing happened at first, which is the behavior I would expect. However, the second time I tested this, the item actually did transfer successfully, and I received the green notice.

Third, when the library attempted the transfer again the correct way (that is, by selecting the Call Number line as the destination instead of the Item line), the item transferred successfully, but they did not receive the green notice.

When I tried to recreate this, the item transferred successfully and I received the green notice.

So I am admittedly not entirely certain if this is a bug or just a one off occurrence, but I wanted to share my findings in case anyone else has experienced this before, as well.