Bug 22395 - Data in 245 field (subfield a or b) will be deleted if it has Quotation Marks
Summary: Data in 245 field (subfield a or b) will be deleted if it has Quotation Marks
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 18.05
Hardware: All All
: P5 - low critical (vote)
Assignee: Bugs List
QA Contact: Testopia
Keywords: regression
Depends on:
Reported: 2019-02-22 14:10 UTC by Kelly McElligott
Modified: 2020-01-06 20:14 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:

Bug 22395: (bug 15836 follow-up) Fix class_sources.class_split_rule FK creation (2.45 KB, patch)
2019-02-27 12:56 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kelly McElligott 2019-02-22 14:10:40 UTC
Experiencing problems with data in the 245 field being deleted when we use the Edit or Edit as New (Duplicate) functions.
If the 245/a or /b has quotation marks in it, all data from the initial quotation mark and after is deleted from the record.

Found a bug similar to this 21986, however, that should have been resolved in the version that is being used (18.11.08).

I tested this on 18.11- and am not seeing the same issue on that version.
Comment 1 Katrin Fischer 2019-02-22 14:40:27 UTC
Possible data loss bug - updating severity.
Comment 2 Phil Ringnalda 2019-02-22 19:18:17 UTC
Not just 245, though that's certainly the most likely field to have double-quotes in it: I tested 100/260/655, all of which are also affected, so there's no reason to think any tag isn't affected.

18.05.06, the value attribute for |"A" is for alibi| is |value=""A" is for alibi"|, 18.05.08 it's |value=""A"(etc.)| so practically speaking it's value="".
Comment 3 Phil Ringnalda 2019-02-22 22:34:55 UTC
Though conveniently, 500s aren't affected, since they are loaded as the content of a textarea element rather than as an attribute of an input element, so failing to escape them doesn't actually matter.
Comment 4 Phil Ringnalda 2019-02-25 20:12:32 UTC
Ah. Bug 21986 removed what had been escaping the quotes prior to 18.05.08, which doesn't cause this bug on 18.11.x or master because they both have the escaping from bug 13618, but that didn't land on 18.05 (or 17.11, which is probably also affected by this bug as of 17.11.14).
Comment 5 Jonathan Druart 2019-02-26 17:11:48 UTC
CCing Lucas (Rmaint 18.05) and Fridolin (Rmaint 17.11)
Comment 6 Fridolin Somers 2019-02-27 08:45:09 UTC
(In reply to Jonathan Druart from comment #5)
> CCing Lucas (Rmaint 18.05) and Fridolin (Rmaint 17.11)

Indeed I see the problem.
I have reverted Bug 21986 from 17.11.x
Comment 7 Jonathan Druart 2019-02-27 12:56:05 UTC Comment hidden (obsolete)
Comment 8 Lucas Gass 2019-02-28 17:03:02 UTC
21986 has been reverted from 18.05.x