Authority Record UI issues

Thanks for the massive set of MARC records! I had asked for just a few samples, but I'm trying to load your complete set on my laptop now.

It would be helpful to me if you could, on your test system:

1) try loading just a few authority records to see if the quantity of records and search response times (or lack thereof) might be introducing some problems

2) Check the JavaScript Console in the staff client (Admin -> Developer -> JavaScript Console) to see if there are glaring errors being reported, particularly in the "Manage authorities" interface.

Re: massive set -- very junky too. I expect to be doing lots of batch removals as somewhere in one of our previous ILS's history there was an "automatic authorities" features that they used for some time. We'll separate wheat from chaff soon.

Regarding js console, performing these steps:

Open Manage Authorities > Perform search for Subject term > Page forward

The JavaScript Console reports no errors, but some minor (?) warnings like:
"Expected declaration but found..."
Unknown property '-moz-outline-style'. Declaration dropped
etc.

I stopped trying to load the complete set and just loaded the first
1000, and wow - there's a lot of 4xx and 5xx entries in there - the UI
might need some tweaking on the MARC Editor context field popup. But
it worked on Fedora 14 / PostgreSQL 8.4 / Evergreen 2.0.3, in both the
MARC Editor and Manage Authorities interfaces.

I'll crank up to 50,000 records and try loading those on my laptop to
see if the delay due to large number of records introduces a problem.

Loaded 50,000 records on my laptop and it's all still working well (albeit the records that have 16 4xx/5xx fields really do a number on the MARC Editor UI; you need to scroll up and down the list).

I'll try loading these onto a clean VM image for the 2.0.3 release and see what happens.

Just upgraded to 2.0.3 (from 2.0.2), and I have the same symptoms. Also, no errors reported in the js console.

Next step -- redo from 1.6.0.4 scratch entire upgrade again.

Minor update FWIW -- Merge record action item does appear to work for me. But Edit and delete do not.

Performed a clean install of Evergreen 2.0.3 on a completely clean Debian Squeeze machine, loaded 50,000 of your authority records, and could not reproduce any of your reported problems. I suspect you have a configuration problem on your server.

FWIW, I go the same symptoms with complete redo of 1.6.1.4 > 2.0.3 system. Restarted with newly refreshed /openils directory, database, and redo of OpenSRF 1.6.2 install. Won't get back at this for a couple of days, but let me know if you've got any other thoughts on what to check, etc.

I'm trying to reproduce this on a public server, but have seen it elsewhere. When I stepped through the javascript with Venkman, it looked as if Mozilla would lose track of what code was running in the pop-up event handler, right after the dojo.forEach that loops through the authority records. This causes the normal context handler to function, giving you the copy/paste menu instead of the authority dialog.

As a datapoint, replacing dojo.forEach with for(;;) did not change the situation on another server exhibiting this behavior, so it's not Dojo or it's crazy closure dances.

Update -- re-ran upgrade steps for 1.6.0.4 system to 2.0.4 (on Ubuntu 10.4 with OpenSRF 1.6.2)

As a complete wildcard, I only included our III sourced Authority records (much less and better quality records).

No success - and same symptoms as originally reported.

Re: local configuration -- can't seem to find any local configuration to account for this error, so let me know if anybody has anything else for me to check. Otherwise I think I'll leave this issue for our eventual production upgrade and then open a support ticket if it happens there to.

Thanks to James Fournie from BC Sitka for providing the a fix for us over beer at Leon's. We found a few other crews with similar symptoms so James mentioned that he had to re-ingest the authority records since his didn't have the 2.0 record id data

I checked our authority records and we didn't have any record id's either after our upgrade from 1.6.1.4 to 2.0.4, so I followed James suggestion to trigger the re-ingest by running a simple update query against the authority.record_entry table. The re-ingest will add the new 901 data with record id's.

This fixed my mangled display issue (via "Manage Authorities") and also now allows me to access authorities in the MARC editor via "right click".

Thanks James!

Ah - that makes so much sense. The database functions evergreen.maintain_control_numbers() and evergreen.maintain_901() need to be invoked to ensure that the 003 field and 901 $c subfield exist in each authority record. I didn't hit that when I loaded your sample records because, of course, when I imported them into a shiny new 2.0 database these functions were invoked at import time so it changed the records to suit.

A SQL statement that would hit every record in authority.record_entry to ensure that these functions get invoked would be "UPDATE authority.record_entry SET active = active WHERE 1 = 1;". Maybe overkill, but better safe than sorry.

Also - clearly I should add some defensive coding to the authority interfaces to handle the case where the authority record does not have a 901 $c or 003!

I'll add this to the 1.6-2.0 upgrade script ... it will take a while to run, but at least authorities will work.

Mike: were you planning to add the UPDATE statement to 1.6-2.0 before cutting 2.0.6? If so, PING! :)

As promised, the upgrade script will says

UPDATE authority.record_entry SET active = active;

now.