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
Medium
Unassigned
3.1
Undecided
Unassigned
3.2
Undecided
Unassigned
3.3
Undecided
Unassigned
3.4
Medium
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
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
Terran McCanna (tmccanna) wrote :

This patch is loaded on a 3.4.2 sandbox with concerto data but I'm not seeing the ID number from the 901c field coming through. In the attached screenshot, the value that is in the associated MARC record is 245.

I'm not sure what the significance is, but I notice that in this particular case if that link was complete it would be: https://bugsquash.mobiusconsortium.org/opac/extras/ac/jacket/small/245 and it would show the "no image" single pixel image.

To get the actual cover, I would need to change the URL to https://bugsquash.mobiusconsortium.org/opac/extras/ac/jacket/small/r/245

Terran, I think that I should be seeing the BIBID value in the atom output, but I'm not seeing that.

https://bugsquash.mobiusconsortium.org/opac/extras/feed/bookbag/atom/29

Any chance the changed XSLT files are not being used? Was supercat reloaded after the changes applied?

Josh

Terran McCanna (tmccanna) wrote :

I'm not sure - I'll try to get this tested again on my own test server after we get through our upcoming upgrade.

Changed in evergreen:
milestone: 3.4.2 → 3.4.3
Terran McCanna (tmccanna) wrote :

I was unable to create a record in Concerto that has different 001 and 901c values, but I WAS able to confirm that this change does indeed put the ID into the image url instead of having a blank ID in the url, so I'm happy to sign off on it!

Without this change, the feed produced this image url (no image):

/opac/extras/ac/jacket/small/

And with the change, the feed produced this image url (image):

/opac/extras/ac/jacket/small/r/216

My sign off at:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1674364_html_feed_atom_coverart_bibid_signoff

tags: added: opac signedoff
Changed in evergreen:
milestone: 3.4.3 → 3.4.4
Changed in evergreen:
milestone: 3.4.4 → 3.5.1
Galen Charlton (gmc) wrote :

Tested and pushed to master, rel_3_5, and rel_3_4. Thanks, Josh and Terran!

Changed in evergreen:
importance: Undecided → Medium
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