Bug 23412 - HTML should be allowed in MARC notes. (5xx fields)
Summary: HTML should be allowed in MARC notes. (5xx fields)
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Assignee: Lucas Gass
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-01 15:39 UTC by Lucas Gass
Modified: 2023-06-08 22:26 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 23412: HTML should be allowed in MARC notes. (5xx fields) (1.54 KB, patch)
2019-08-01 16:19 UTC, Lucas Gass
Details | Diff | Splinter Review
Bug 23412: HTML should be allowed in MARC notes. (5xx fields) (1.59 KB, patch)
2019-08-02 18:26 UTC, Maryse Simard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lucas Gass 2019-08-01 15:39:07 UTC
Some librarians like to add HTML in the 5xx fields to display links, etc. We should allow $raw filters in this case.
Comment 1 Lucas Gass 2019-08-01 16:19:44 UTC
Created attachment 91909 [details] [review]
Bug 23412: HTML should be allowed in MARC notes. (5xx fields)

TEST PLAN
1. Add some HTML to one of the 5xx fields that displays in the OPAC: <a href ="www.koha-community.org">koha</a>
2. Go to the record in the OPAC and look under the 'Title notes' tab.
3. See that the HTML displays literally.
4. Apply patch
5. Look at the 'Title notes' tab again.
6. HTML displays correctly
Comment 2 Maryse Simard 2019-08-02 18:26:13 UTC
Created attachment 91936 [details] [review]
Bug 23412: HTML should be allowed in MARC notes. (5xx fields)

Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Comment 3 Marcel de Rooy 2019-08-16 07:35:11 UTC
What about regular use of chars like < and & in a note.
Alice & Bob e.g. becomes now Alice $ Bob

This might need a bit more thought?
Comment 4 Katrin Fischer 2019-08-17 06:28:02 UTC
(In reply to Marcel de Rooy from comment #3)
> What about regular use of chars like < and & in a note.
> Alice & Bob e.g. becomes now Alice $ Bob
> 
> This might need a bit more thought?

I've done some testing too, these were my 500$a:

<a href ="http://www.koha-community.org">koha</a>
http://www.koha-community.org
Alice & Bob 

They all display nicely, with the second already being displayed as a link without the patch(!). So I don't see the breakage Marcel points out. But what breaks is:

Berlin <Germany> 

With the browser hiding the part <Germany>. We often see this in older data as it used to be a common cataloguing practice. There are also other use cases for <> like mathematic formulas that we could break display with this change.

Note: this also only changes the OPAC, but not the staff display.
Comment 5 Fridolin Somers 2019-09-23 15:28:10 UTC
I think we should use html_line_break filter like it used to be : to allow HTML and also present simple multi-lines text.

Patch must cover staff and basket on MARCNOTES and notes.

I'm on a patch and a nice test plan.
Comment 6 Fridolin Somers 2019-12-13 08:28:05 UTC
(In reply to Fridolin SOMERS from comment #5)
> I think we should use html_line_break filter like it used to be : to allow
> HTML and also present simple multi-lines text.
> 
> Patch must cover staff and basket on MARCNOTES and notes.
> 
> I'm on a patch and a nice test plan.

Oups this is an old statement.
I have no patch nor test plan.

We should also fix staff interface no ?
Comment 7 Katrin Fischer 2019-12-13 08:30:51 UTC
I am still not sure we should bend the standard like that... especially as it will break things like the sample below with the <> as part of the text.
Comment 8 Lucas Gass 2022-02-02 23:15:34 UTC
(In reply to Katrin Fischer from comment #7)
> I am still not sure we should bend the standard like that... especially as
> it will break things like the sample below with the <> as part of the text.

I think you are correct and we should not bend the standard like this, marking this as wont fix.
Comment 9 David Cook 2022-07-25 23:56:15 UTC
(In reply to Lucas Gass from comment #8)
> (In reply to Katrin Fischer from comment #7)
> > I am still not sure we should bend the standard like that... especially as
> > it will break things like the sample below with the <> as part of the text.
> 
> I think you are correct and we should not bend the standard like this,
> marking this as wont fix.

I'm not sure I follow. Which standard would be bent by allowing HTML?
Comment 10 David Cook 2022-07-25 23:59:37 UTC
On the topic of standards, I think that this is my favourite MARC field:

887 - Non-MARC Information Field (R)
https://www.loc.gov/marc/bibliographic/bd887.html

I think it was probably intended for XML data outside the MARC schema, but I've seen some wild things in there before...
Comment 11 David Cook 2022-07-26 00:00:39 UTC
(In reply to David Cook from comment #10)
> On the topic of standards, I think that this is my favourite MARC field:
> 
> 887 - Non-MARC Information Field (R)
> https://www.loc.gov/marc/bibliographic/bd887.html
> 
> I think it was probably intended for XML data outside the MARC schema, but
> I've seen some wild things in there before...

Technically, I would say that XHTML is allowed in the 887 at least.
Comment 12 Katrin Fischer 2022-07-26 07:11:56 UTC
I think the problem is not the HTML so much as the expectation that it should render... and then it will be used for formatting, which is not a good mix usually - formatting and data.