https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 --- Comment #3 from Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> --- (In reply to Katrin Fischer from comment #2)

Hi Marjorie, what did you enter/expect? This field expects only a link and no HTML and will display as a link in OPAC automatically (so I think entering as HTML directly would probably create issues)

Hi Katrin, Here is a sample code   <a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the resource</a>   I do not understand why it no longer works in version 19.05. Marjorie -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 --- Comment #5 from Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> --- (In reply to Jonathan Druart from comment #4)

We expect $u to be the link of the resource, a link is made around the resource.

If you put your link directly in $u, you will have a link built automatically. Is not it what you want?

Hi Jonathan, Sometimes the url is very long and being able to register html tags allows you to see only a short text replacing the url. Is there an existing parameter not to see the complete url in the url item field? As for the marc field 856$u and 856$y? Marjorie -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 --- Comment #7 from Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> --- (In reply to Jonathan Druart from comment #6)

Salut Marjorie,

If you turn URLLinkText off, the "Link to resource" link will be displayed instead of the URL. I think it's what you are searching for.

URLLinkText is just for field 856 in biblio notice. Description If the 856 field does not have a subfield 3 or y defined, the OPAC will say ‘Click here to access online.^ If you would like the field to say something else enter that in this field. My problem is for field 952$u (marc21). This code put in 952$u works in 18.05 not in 19.05. <a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the resource</a> I do not understand why it no longer works. Regards Marjorie -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I've tested in 17.11 and it works, but only 'by accident' because the browser ignores the very invalid HTML it creates: <a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the resource</a>"> <a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the resource</a></a> The change on master is: <a href="%3Ca%20href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'%3ELink%20to%20the%20resource%3C/a%3E">Link to resource</a> We are now escaping the content entered in $u. I feel we need a better, different way than adding HTML to this field to be able to specify a link text. Is there a separator we could use? url | linktext ? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 --- Comment #10 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Apart from that, I think we should not allow html in a field called uri. A uri is what it is. And it is not html. We can render it as an html link and that would fail if we put html in this field. So the question should probably be: Where do you expect this uri to be presented as a link while it does not? The reference to bug 23194 is about public notes, a field with completely different content. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 --- Comment #12 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #11)

I think the issue here is not that you don't want it to appear as link some cases or that it doesn't, but that we have no way to configure a link text (see comment#5) or shorten very long URLs.

Which you could say, is actually a limitation of the MARC standard. Since our 952$u comes from 852$u. MARC does not allow you to define link text here. The solution too provide a generic text (as in 856$u) is imo rather poor. Especially when we add multiple URIs in one field. What you could do, is: add an item field urllinktext and provide a way to enter that field in the item editor somehow. It would live in items and not in MARC. But it could be used whenever we want to render an item URI. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #14 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #13)

I think we go way beyond 852 in a lot of areas - which is also the problem: There are no more free subfields in Koha to use for this. And if you have repated $u you also get the issue of sequence. Btw - if we used MFHD (MARC for Holdings Data, we could have a full 856 there, so it's not really a limitation of the standard).

The item editor is not made to resort the item subfields and I also feel like that would not be a good solution and more error prone / harder to handle for catalogers.

Of course, I think the only reason we use the 952 for item/holdings data is because we forced Zebra (and to a lesser degree Elasticsearch) to use MARC. Neither Zebra nor Elasticsearch actually require MARCXML, so another way forward is to have Koha Item Metadata that we create and use however we want. (We'd just need a MARC export for it for metadata exchange with other systems, and in that case we could leave off things like link text.) A complicated avenue for sure, but it's an option. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 --- Comment #16 from Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> --- (In reply to David Cook from comment #15)

(In reply to Jonathan Druart from comment #6)

...

Salut Marjorie,

If you turn URLLinkText off, the "Link to resource" link will be displayed instead of the URL. I think it's what you are searching for.

Honestly, I think this is the answer though. I'd be inclined to mark this as resolved.

Hi David, Leaving blank in UrlLinkText system preference does not solve the problem for the 952 $u. Unless I misunderstand when you say "If you turn URLLinkText off" If the system preference worked for the 952 $u, that would be perfect, the links would not be visible either in the item, but only the text of the system preference and we could remove the html tags. Marjorie -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25483 --- Comment #18 from Marjorie Barry-Vila <marjorie.barry-vila@collecto.ca> --- (In reply to Katrin Fischer from comment #17)

...

If the system preference worked for the 952 $u, that would be perfect, the links would not be visible either in the item, but only the text of the system preference and we could remove the html tags.

Marjorie

It will work with 20.05 - bug 15352

ok great! It's enough for me. I think that the html tags should never have been in the 952$u but our customers do not always do what they are told ... I just wanted to understand the change in behavior between 18.05 and 19.05. Now I understand (thanks to comment 8) The bug can be marked as resolved for me Marjorie -- You are receiving this mail because: You are watching all bug changes.