html item feeds - cover art lookup based off of ISBN

Bug #1674364 reported by Josh Stompro on 2017-03-20
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned
3.1
Undecided
Unassigned
3.2
Undecided
Unassigned

Bug Description

The xsl for converting atom to html tries to add links to cover art based on the titles ISBN, instead of using the newer method of by record ID. Additionally, the current ISBN processing code doesn't seem to handle all ISBN's correctly. Having 020 entries like the following results in no cover art link being generated.
=020 \\$a9781410496850$q(hardcover ;$qlarge print)
=020 \\$a1410496856$q(hardcover ;$qlarge print)

I found one that did work, and the main difference that I can see is that it only has one 13 digit ISBN.
=020 \\$a9786315169342

The section of ATOM2XHTML.xsl that deals with adding cover art is at -
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/xsl/ATOM2XHTML.xsl;hb=HEAD#l302

I'm really clueless about xslt, so I'm not sure what is going wrong here. I think that the code is saying that whenever we are not on the first ISBN entry, and the length is not greater than 9, set the src for the image to a default value for cover art, that won't ever return anything. So any time there is more than one ISBN, the 2nd entry will always cause it to be blanked out. So you will never get cover art for titles with more than one ISBN.

The current behavior can probably be fixed, but it would be better to just use the record ID instead.

I think that maybe the MARC21slim2ATOM.xsl needs to include the 901c, as the URN:RECORDID, since in theory the TCN(001) doesn't need to equal the record ID?

http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/xsl/MARC21slim2ATOM.xsl;hb=HEAD

Terran McCanna let me know about this issue and has fixed this for PINES and has provided the files she updated at.
https://drive.google.com/file/d/0B_YSoBdcQ5kZTFU1c2dFUkdkOGc/view - ATOM2XHTML.xml
https://drive.google.com/file/d/0B_YSoBdcQ5kZWkVxOXllRmJSUU0/view - MARC21slim2ATOM.xml

Thanks
Josh

I got the RSS link one of my catalog lists viewed it on an RSS reader (feedly) and noticed that it only had one image (out of 4 total records).
The Fifth Season did not have an image despite having only one 13-digit ISBN 9780316229296
Mr. Penumbra's 24 hour bookstore did have an image--and also had one 13-digit ISBN

Terran McCanna (tmccanna) wrote :

Yes, the ISBN method of lookup just isn't reliable. The code should be changed to use TCN like the catalog pages do.

Changed in evergreen:
status: New → Confirmed

I think we should not use the TCN, 001 for pulling the data. Some sites do use TCN values that are not the same as the database bib id number. I think we need to use the 901c value to pull the cover art.

Here is a working branch that pulls out the 901c as a URN:BIBID: value. And then uses that in the ATOM2HTML.xsl for cover art.
user/stompro/lp1674364_html_feed_atom_coverart_bibid
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1674364_html_feed_atom_coverart_bibid

Testing notes.

The xsl files that seem to be used are in /openils/var/xsl, not the ones under /openils/var/web/opac/extras/xsl/

Restart supercat to reload files after changes.
osrf_control -l --service open-ils.supercat --restart

I used a bookbag to display a group of results with links like
 /opac/extras/feed/bookbag/atom/<bookbagid>
 /opac/extras/feed/bookbag/html-full/<bookbagid>

Josh

tags: added: pullrequest
Michele Morgan (mmorgan) on 2019-03-07
Changed in evergreen:
milestone: none → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers