Web Client: fool proof transferring vol/copy process

Bug #1737812 reported by tji@sitka.bclibraries.ca
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Undecided
Unassigned
3.0
Confirmed
Undecided
Unassigned
3.1
Confirmed
Undecided
Unassigned

Bug Description

I am inviting comments. I found the current volume/copy transfer process is prone to mistakes.

This is a two-steps process: marking a destination, then transferring the source vol/copy.

The current behaviour:

There are four options of marking a destination on Holdings View.

1. Mark For > Volume Transfer
2. Actions > Choose a Library as V/C Transfer Destination
3. Actions > Mark > Library as Volume Transfer Destination
4. Actions > Mark > Volume as Item Transfer Destination

There are five options of making the transfer:

Actions > Transfer > Volumes to Previously Marked Record
Actions > Transfer > Volumes to Previously Marked Library
Actions > Transfer > Volumes to Previously Marked Record and Library
Actions > Transfer > Copies to Previously Marked Library
Actions > Transfer > Items to Previously Marked Volume

It appears there could be four destinations existing at the same time. These four destination persist until a new one of its kind is marked, even after logging out of EG, closing the browser and shutting the computer.

Only one of these four destinations is visible and can be reset (cleared) (the one marked via Mark For > Volume Transfer).

The five options of making the transfer are always available (meaning none of them is greyed out for any reason). Clicking anyone will transfer the source to the corresponding destination. A misstep here will send the source to the wrong destination.

This function is not expected to be used by cataloguers on daily basis. It may be challenging for cataloguers to choose the right transfer option every time. They need to fully understand and remember how the destination and transfer options are paired up. It will not be an easy task for a used-once-in-a-while function. The consequences of choosing the wrong option is transferring the source to the wrong destination due to the persistent hidden destinations.

Suggested changes:

1. keep only one volume destination and one copy destination at a time.
2. keep only one option for volume transfer and one option for copy transfer
3. show a option popup indicating the destination bib (ideally with title) and vol/library for staff choose YES or NO. This is especially important if the above 1 & 2 can not be done.

I see the merit of having multiple destinations, which allows staff to shuffle copies/volumes among two bibs and within one bib at a time. But I think this scenario rarely occurs. Considering the added complexity and consequence of the misstep, a mistake-proof process makes more sense to me.

Tina Ji
BC Libraries Coop

Revision history for this message
Kate Coleman (katecoleman) wrote :

+1

Having just tried to transfer, deciding what I was supposed to do was very confusing.

Revision history for this message
Elaine Hardy (ehardy) wrote :

+1

I agree that it is a very confusing process that will lead to errors. The XUL client handles this much better, including the popup with the destination vol and bib record.

Elaine Hardy (ehardy)
Changed in evergreen:
status: New → Confirmed
Andrea Neiman (aneiman)
tags: added: cataloging webstaffclient
Revision history for this message
Mike Rylander (mrylander) wrote :

NTS: Looking at this from the code point of view, this would amount to:
 * The record-level "mark for vol transfer" will record the marc target AND remove the library target, if currently remembered.
 * The holdings maint action "mark library as vol transfer destination" will be the only action-menu vol-transfer-dest option, and will record BOTH the record and library destination.
 * There will be only one vol-transfer action. The existing copy transfer actions will stay as-is.

Revision history for this message
Mike Rylander (mrylander) wrote :
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.2-beta
tags: added: signedoff
Revision history for this message
Elaine Hardy (ehardy) wrote :

I tested several variations of this, all worked as expected and this does simplify transferring items and volumes:

Volume transfer
To different bib record – one vol, one library, no vol for library on destination record
 Mark Library as Volume Transfer Destination on destination record (from actions menu)
 From vol to be transferred: Transfer Volume to Previously Marked Destination (from actions menu)
 Works as expected (no warning dialog as with the XUL client in any of the transfers)
To different bib record where vols for libraries exist:
 Mark vol/library as destination (from actions menu)
 Transfer vol (s) from other record (from actions menu) (can transfer multiple vols from same library to another record)
 Works as expected

Item Transfer:
To different library (changing owning library) (same record, volume for item transfer exists)
 Mark volume as item transfer destination (from actions menu)
 Transfer item(s) from other library using Transfer items to previously marked volume in actions menu
 Works as expected
Transferring item(s) when vol does not exist on same or different bib record
 Works as expected since can now create empty vol.

Since there is still Volume Transfer under the Mark for menu that marks the records, I did test that (since it works in the web client). It no longer works with this branch. Suggest removing Volume Transfer form the Mark for menu if it is to remain inactive.

Dan Wells (dbw2)
Changed in evergreen:
assignee: nobody → Dan Wells (dbw2)
Revision history for this message
Dan Wells (dbw2) wrote :

I have a simple commit to remove the dead menu option mentioned by Elaine, as I agree that this was the intention of this simplification plan.

Also, moving discussion to an omnibus bug for this omnibus branch...

Please see bug #1773417.

Changed in evergreen:
assignee: Dan Wells (dbw2) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.