https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36111 --- Comment #48 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Caroline Cyr La Rose from comment #46)
(In reply to Katrin Fischer from comment #44)
I am not sure about the proposed patches here as what they actually do and what is advertised in the bug title doesn't match up.
1) This changes the current behavior beyond not displaying $h:
We won't be displaying any "Online resources" info if there isn't a $u. The LOC documentation lists a few examüles where we don't have a $u:
https://www.loc.gov/marc/bibliographic/bd856.html
856 1#$amaine.maine.edu$cMust be decompressed with PKUNZIP$fresource.zip 856 0#$akentvm.bitnet$facadlist file1$facadlist file2$facadlist file3 856 0#$auicvm.bitnet$fAN2 856 2#$amadlab.sprl.umich.edu$p3000 856 10$zFTP access to PostScript version includes groups of article files with .pdf extension$aftp.cdc.gov$d/pub/EIS/vol*no*/adobe$f*.pdf$qapplication/pdf
So are we sure there are no unintended side effects of this change?
I can't really answer the more technical questions, I will leave this to Matthias, but I can answer this one. Currently, there is a link "Click here to access online" whether there is a $u or not and the href is the contents of the $u. That is definitely not wanted, I don't think. If anyone currently uses the 856 field without $u, they must have display problems. I think the 856$u alternative in MARC is to use a combination of $a, $d, and $f. Those subfields are currently not supported in the XSLT. I don't really see how we could introduce a regression if the current behaviour is broken and the alternative behaviour is not implemented.
You're right that it kind of veered off from the title of the bug. It started with my issue with 856$h, but as Matthias looked at the code, we noticed that only $3, $u, $y and $z were implemented in the display, with the $u as the href and it was displayed if there is any 856 subfield. Since the link depends on the $u, I instructed him to hide the whole thing if there is no $u. I will change the bug's title to reflect more the current behaviour.
If we want to implement $a/$d/$f for those who use it, I think it should be done in the context of another bug.
All good points :) I didn't have the time to dig deeper than checking if it could be a valid use case to have an 856 without $u. So I put the question out there. I am ok with relying on $u for now, but: * Could we maybe adjust bug description and release notes to reflect the slightly different route we've taken? * When making the comments 2)-5) I assumed we would take this route, so they should still be valid. Would be great to get some feedback/follow-ups on those. :) -- You are receiving this mail because: You are watching all bug changes.