https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36111
--- Comment #48 from Katrin Fischer <katrin.fisc...@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. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
