https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6892 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #18 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Hi Jan, thanks for picking this one up. The OPAC follow-up is good and does what it says: with TrackClicks on, uri=bugs.koha-community.org becomes uri=http%3A%2F%2Fbugs.koha-community.org, and with tracking off the Online resources block comes out identical to before. Hoisting the AddMissingProtocol call into a variable so all three branches share it also looks right to me. The first patch is a problem, though. It comes down to: in the "otherwise" branch it drops the <a> instead of leaving it alone. For example: a record with 856 ind1=0 $u mailto:someone@example.com. On main that link works. With the patch it renders as plaintext, because "mailto" doesn't start with "http" and ind1 isn't 4. Same for telnet://locis.loc.gov (ind1=2) and ftp://ftp.gnu.org/gnu/ (ind1=1). The protocols from the indicator list in comment #2. And that applies to any other $u subfield too, e.g. 505 $u mailto:someone@example.com. Katrin suggested in comment #4 to add http:// for ind1=4 and leave the content alone otherwise. Leaving it alone fixes the reported case w/o breaking the others. Another thing is that the check reads tab0X.{tag,tag_ind} and MARCdetail.pl only fills those in the standard display path. Two settings break it: 1. hide_marc=on: the tag holds the fields label instead of 856, so a protocol-less 856 ind1=4 gets no link. 2. LabelMARCView=economical: repeated fields get tag = '', so only the first 856 in a run of 856s gets the http:// prefix, the rest lose their links. On comment #6: since this seems to have stalled this bug, both patches are display only, so no modification of stored data. -- You are receiving this mail because: You are watching all bug changes.