Bug 41686 - Strange unescaping of html-entities in itemcallnumber
Summary: Strange unescaping of html-entities in itemcallnumber
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 25.05
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-22 13:44 UTC by Andreas Jonsson
Modified: 2026-02-03 16:02 UTC (History)
2 users (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Jonsson 2026-01-22 13:44:11 UTC
Go to a bibliographic record and edit an item.

In itemcallnumber type:

a &

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

Edit the item again and change to

a & 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 '& ' - 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 '& ' isn't unescaped, despite that also being defined. Nor are '< ' or '> '. I didn't try the whole list of named character references from the spec, but if < isn't, there's no reason to think that ϶ would be.