Bug 41686

Summary: Strange unescaping of html-entities in itemcallnumber
Product: Koha Reporter: Andreas Jonsson <andreas.jonsson>
Component: CatalogingAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: m.de.rooy, phil
Version: 25.05   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Andreas Jonsson 2026-01-22 13:44:11 UTC
Go to a bibliographic record and edit an item.

In itemcallnumber type:

a &amp;

Save. The result is, as expected, that the itemcallnumber will be literally 'a &amp;'

Edit the item again and change to

a &amp; b

Save.  Now the itemcallnumber will be 'a & b' as if the string has been subject to an extra unescaping of html-entities.
Comment 1 Phil Ringnalda 2026-02-03 16:02:27 UTC
Not just itemcallnumber, it happens for every item field you can type in, and also for bib records.

You don't need the 'b', just '&amp; ' - without the space it isn't unescaped. And without the semicolon it isn't unescaped, though &amp is one of the things where browsers don't require it. And '&AMP; ' isn't unescaped, despite that also being defined. Nor are '&lt; ' or '&gt; '. I didn't try the whole list of named character references from the spec, but if &lt; isn't, there's no reason to think that &backepsilon; would be.