Fast Item Add no longer opens record after copy is created

Bug #1277556 reported by Jason Boyer on 2014-02-07
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
2.5
Undecided
Unassigned
2.6
Undecided
Unassigned

Bug Description

Evergreen 2.5.2
OpenSRF 2.2.X
PostgreSQL 9.1.11
Ubuntu 12.04

In Evergreen 2.2.2, when using the Fast Item Add function of the MARC Editor (Z39.50 import, Cataloging Menu -> Create new MARC Record, etc.) the new record is displayed in the opac after "Modify/Create Copies" is clicked in the item editor.

In Evergreen 2.5.2, the record is not loaded after dismissing the item editor. There's no indication that there was a problem or not. If Fast Item Add is NOT used, the record is loaded after the new record is saved, or imported.

Reading the relevant bits of the code it's obvious that the intention is still to open the record in the opac, but somewhere along the line that's not happening. There aren't any errors in the JS Console that appear to be related, and the logs show no problems.

When running the staff client with the -console option, here are 2 examples of importing a record with Z39.50, Fast Item Add selected both times:

2.2:
Loading OpenILS/util_overlay.xul for http://mig.evergreen.lib.in.us/xul/isl_rel_2_2_2/server/cat/z3950.xul
Loading constants.js
Loading OpenILS/util_overlay.xul for http://mig.evergreen.lib.in.us/xul/isl_rel_2_2_2/server/cat/marcedit.xul
Loading OpenILS/util_overlay.xul for http://mig.evergreen.lib.in.us/xul/isl_rel_2_2_2/server/cat/copy_editor.xul
Loading OpenILS/util_overlay.xul for http://mig.evergreen.lib.in.us/xul/isl_rel_2_2_2/server/cat/bib_brief.xul?docid=20128923

Loading OpenILS/util_overlay_chrome.xul for chrome://open_ils_staff_client/content/cat/opac.xul
Loading OpenILS/util_overlay_chrome.xul for chrome://open_ils_staff_client/content/util/browser.xul?name=Catalog
running event rdetail:recordRetrieved
Loading OpenILS/util_overlay.xul for http://mig.evergreen.lib.in.us/xul/isl_rel_2_2_2/server/cat/bib_brief.xul?docid=20128923
running event rdetail:MFHDDrawn

2.5:
Loading OpenILS/util_overlay.xul for oils://remote/xul/isl_rel_2_5_2/server/cat/z3950.xul
Loading constants.js
Loading OpenILS/util_overlay.xul for oils://remote/xul/isl_rel_2_5_2/server/cat/marcedit.xul
Loading OpenILS/util_overlay.xul for oils://remote/xul/isl_rel_2_5_2/server/cat/copy_editor.xul
Loading OpenILS/util_overlay.xul for oils://remote/xul/isl_rel_2_5_2/server/cat/bib_brief.xul?docid=20142544

Kathy Lussier (klussier) wrote :

Confirmed in master.

If using the unified volume/copy editor, this is not an issue. When you click the "Create record" button, you can see the unified volume/copy editor replacing the New MARC record form in the tab - See http://www.screencast.com/t/sskBVF96shf . When the copy record is subsequently saved, the record simply refreshes in that same tab.

However, when using the separate copy editor, clicking the "Create record" button appears to open the copy editor in a separate window. See http://www.screencast.com/t/keSjbOeHTr4. Saving the copy record then returns the user to the previous window where the New MARC record form still sites.

I wonder if the difference in location for where the copy editor loads is the reason why we see this problem only with the separate copy editor.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Blake GH (bmagic) on 2014-07-01
tags: added: pullrequest
Kathy Lussier (klussier) on 2014-07-02
Changed in evergreen:
milestone: none → 2.next
Kathy Lussier (klussier) on 2014-08-27
tags: added: signedoff
Ben Shum (bshum) wrote :

Thanks for the patch Blake, and the testing Remington. I've pushed this fix to master, rel_2_6, and rel_2_5. (with one minor change to alter Blake's signoff and authorship to include his full name)

Changed in evergreen:
milestone: 2.next → 2.7.0-beta2
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers