Opening multiple Volume and Copy Editor windows causes "network failure"

Bug #623445 reported by Ben Ostrowsky
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Low
Unassigned

Bug Description

Reported in 1.6.0.7:

Here are the steps we took to get the error:

1. Search the catalog
2. Pull up a record
3. Action for this Record
4. Holdings Maintenance
5. Right click on library -> Add Volumes
6. Add volume, call number, copies and barcode -> Edit then create
7. Open another tab and repeat steps 1-5 (but for a different bib)

And Network Failure error message displays.

Call to [open-ils.cat.biblio.record.marc_cn.retrieve] failed for session..., thread trace [1]:\nCan't call method \"marc\" on an undefined value at /openils/bar/perl5/OpenILS/Application/Cat.pm line 316.

It has been reported that the 'admin' user is immune to this, but rank-and-file catalogers (who would like to be able to multitask) are experiencing this problem.

Related branches

Revision history for this message
James Fournie (jfournie) wrote :

I was able to recreate this, but only on a Windows client, not on Mac. It appears this happens when you add the volumes and then the "Edit Item Attributes" copy editor screen opens, but you ignore it or otherwise don't close it and try to open another volume editor, it produces this error.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Ben Shum (bshum) wrote :

One of our libraries mentioned us this error message. I was able to duplicate the error with my Linux staff client. Our server version is 1.6.0.2 though (probably still same issue at hand).

Tried it using both admin and staff accounts. We saw the error both times. Pretty much any time that the volume creator is open and you try to open a second one you receive this error.

I assume that this is only a problem when we try to launch a second volume creator window. So we'll just tell people not to do that for now.

Revision history for this message
Dan Scott (denials) wrote :

In trunk, as of 2010-11-25, the new "open holdings maintenance in a tab instead of a window" implementation seems to help avoid this problem; albeit perhaps in an annoying way. Once the item attribute editor from the first holdings maintenance tab is opened in a new window, you can't switch focus to a different tab.

You can use CTRL+Tab or File->New tab to open a new tab, search for another bib, and then open holdings maintenance for that bib - but the request for holdings seems to block until the item attribute editor window from the first holdings maintenance tab is closed.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Not confirmed on later versions and recent changes appear to make this a non-issue.

Changed in evergreen:
status: Confirmed → Won't Fix
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.