Zotero fails to capture metadata

Bug #1776954 reported by Dan Scott
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Low
Unassigned
3.1
Won't Fix
Undecided
Unassigned
3.2
Won't Fix
Undecided
Unassigned
3.3
Won't Fix
Low
Unassigned
3.4
Fix Released
Low
Unassigned
3.5
Fix Released
Low
Unassigned

Bug Description

* Evergreen 3.1.2

Symptom: Zotero successfully captures rich data from some catalogue records, but falls back to just a regular web page snapshot for others.

Cause: For some records, biblio.record_entry.tcn_source field is an empty string (''), which results in the MARCXML that is generated to have an empty 901 $b subfield (<subfield code="b" />), which causes the Zotero MARCXML translator to error out.

The reason the tcn_source for some records are empty strings is because the Perl record import code sets the value to an empty string if it can't find any other source (e.g. OCLC number) to avoid causing a Perl warning in the logger info call. The empty string then gets passed to the database, meaning that it satisfies the non-NULL constraint and doesn't invoke the default value of 'AUTOGEN'.

The simple fix is to not set the value of the tcn_source field in the bib record object if the corresponding variable evaluates to false (such as if it's an empty string).

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

A branch with one of the larger ratios of commit description to actual patch length is available in the working repository at user/dbs/lp1776954_avoid_empty_string_tcn_source (http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/lp1776954_avoid_empty_string_tcn_source).

tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.1.3
Changed in evergreen:
milestone: 3.1.3 → 3.1.4
Changed in evergreen:
milestone: 3.1.4 → 3.1.5
Changed in evergreen:
milestone: 3.1.5 → 3.1.6
Changed in evergreen:
milestone: 3.1.6 → 3.2.1
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Changed in evergreen:
milestone: 3.2.2 → 3.2.3
Changed in evergreen:
milestone: 3.2.3 → 3.3-beta1
Dan Wells (dbw2)
Changed in evergreen:
importance: Undecided → Low
assignee: nobody → Dan Wells (dbw2)
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
Galen Charlton (gmc)
Changed in evergreen:
assignee: Dan Wells (dbw2) → Galen Charlton (gmc)
Changed in evergreen:
milestone: 3.3.1 → 3.3.2
Changed in evergreen:
milestone: 3.3.2 → 3.3.3
Changed in evergreen:
milestone: 3.3.3 → 3.3.4
Changed in evergreen:
milestone: 3.3.4 → 3.3.5
Changed in evergreen:
milestone: 3.3.5 → 3.4.2
Changed in evergreen:
milestone: 3.4.2 → 3.4.3
Changed in evergreen:
milestone: 3.4.3 → 3.4.4
Changed in evergreen:
milestone: 3.4.4 → 3.5.1
Changed in evergreen:
milestone: 3.5.1 → 3.5.2
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Seems a big shame this took so long to make it in. Committed to master, rel_3_4, and rel_3_5 with a commit adding release notes about the potential need to update existing records with blank TCN Source.

Thanks, Dan!

Changed in evergreen:
status: New → Fix Committed
assignee: Galen Charlton (gmc) → nobody
milestone: 3.5.2 → 3.6-beta2
Changed in evergreen:
status: Fix Committed → Fix Released
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.