Bug 11199 - 008 value builder skips invalid characters and collapses remaining data
Summary: 008 value builder skips invalid characters and collapses remaining data
Status: RESOLVED DUPLICATE of bug 21053
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-04 17:47 UTC by Elaine Bradtke
Modified: 2021-02-26 19:12 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elaine Bradtke 2013-11-04 17:47:02 UTC
This is a problem with imported records where the # character is present instead of a blank (though it also seems to happen if there is any character present that is not in the available lists). 
It only happens if you open the 008 value builder to edit the field after the record has been imported.

Here's an example of a problematic 008:
130515s2006####stka###gr#####000#0#eng#d

If I edit the record and open the 008 value builder, Koha
automatically changes it to:
130515s2006
It ignores all the # characters, and shifts everything over, thus changing characters that were valid in their original position into invalid characters (or incorrect characters, though valid) in their new positions.  If a character in a new position is invalid, Koha ignores it as well and collapses the data. . . 
Because the invalid characters are still there (though they are ignored)if you try to edit the above 008 in the value builder, changes don't always end up where you think you put them. The only way to be certain all positions are entered correctly is to return to the MARC editing page, clear the contents of the 008 and start over.

This is what it looks like after manually clearing the field and entering
the information:
131030s2006    stka   gr     000 0 eng d
The # have all been turned into blanks.
Comment 1 Owen Leonard 2016-08-10 15:43:37 UTC
This is still valid in master.
Comment 2 Phil Ringnalda 2021-02-26 19:12:03 UTC
Not so much "skips invalid characters" as "is cut off after unescaped characters that have special meaning in URLs". Fixed by bug 21053.

*** This bug has been marked as a duplicate of bug 21053 ***