Bug 9874 - Adding subfield «ampersand» produce unexpected behaviours
Summary: Adding subfield «ampersand» produce unexpected behaviours
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic data support (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-20 16:07 UTC by Pablo AB
Modified: 2020-11-30 21:45 UTC (History)
2 users (show)

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


Attachments
Screenshot of what it happens if you tried to open a non-escaped character (20.80 KB, image/jpeg)
2015-04-10 11:58 UTC, Pablo AB
Details
Screenshot after trying to delete such subfields. (25.73 KB, image/jpeg)
2015-04-10 11:59 UTC, Pablo AB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pablo AB 2013-03-20 16:07:52 UTC
On Koha v3.10.03.000, one of the librarians thought that English letters and numbers where not enough on 952 holdings subfield, so created new subfields on one the framework. The problem is, choosing ampersand, "&" produce unexpected behaviours, like not been able to delete the subfield, or showing the that subfield while trying to see the others. Creating subfields with other strange characters, like "ñ" (http://en.wikipedia.org/wiki/%C3%91) can be handled by Koha.
In other words, table marc_subfield_structure, tagfield=952 (or any?), frameworkcode=MYFW (or any), produce: tagsubfield=&
The solution is going to the table and removing the row manually (SQL)
The link to remove that subfield might give a clue of the problem, just after tagsubfield http GET parameter:
http://myserver:8080/cgi-bin/koha/admin/marc_subfields_structure.pl?op=delete_confirm&tagfield=952&tagsubfield=&&frameworkcode=LIB
Should not validated Koha what subfields will create?
Comment 1 Jonathan Druart 2015-04-10 08:39:33 UTC
This is fixed, I have tried with a subfield 'é' and 'ñ' and it works quite well (I have also tried to save the record/edit again, all is fine).
Comment 2 Pablo AB 2015-04-10 11:56:55 UTC
This bug isn't fixed yet. Tried with my 3.18.05.100 Koha and still there.
As I said on the first comment, the problem is not with those other characters but with ampersand (and maybe others like "?"). Those are used on query section of the URI by Koha (I'm pretty sure that's the root of the bug). RFC 3986 describes the URI format, such as what characters are permitted and what must be escaped. Koha doesn't escape ampersands.
I'll upload two screenshots to illustrate the problem.
Comment 3 Pablo AB 2015-04-10 11:58:18 UTC
Created attachment 37642 [details]
Screenshot of what it happens if you tried to open a non-escaped character
Comment 4 Pablo AB 2015-04-10 11:59:11 UTC
Created attachment 37643 [details]
Screenshot after trying to delete such subfields.
Comment 5 Jonathan Druart 2015-04-10 15:26:00 UTC
(In reply to Pablo AB from comment #2)
> This bug isn't fixed yet. Tried with my 3.18.05.100 Koha and still there.
> As I said on the first comment, the problem is not with those other
> characters but with ampersand (and maybe others like "?"). Those are used on
> query section of the URI by Koha (I'm pretty sure that's the root of the
> bug). RFC 3986 describes the URI format, such as what characters are
> permitted and what must be escaped. Koha doesn't escape ampersands.
> I'll upload two screenshots to illustrate the problem.

Sorry, I read too quickly the description, you are right, it is still broken with '&'.
Comment 6 Jonathan Druart 2015-04-10 15:28:05 UTC
But... why do you want to use this character? :)
Comment 7 Pablo AB 2015-04-10 15:36:37 UTC
Don't problem Jonathan :)
I don't want it, but a creative librarian think it was a good idea and hence found the bug. I always feel uncomfortable getting out of [0-9a-z] subfields, even «The data element may be any ASCII lowercase alphabetic, numeric, or graphic symbol except blank» (http://www.loc.gov/marc/specifications/specrecstruc.html )

Maybe this bug represent a particular case of a major bug. Koha *always* / anywhere should escape certain characters (RFC3986) while using them on URI.
Comment 8 Owen Leonard 2019-11-20 16:45:02 UTC
This appears to have been fixed, presumably via the extensive work we've done to properly escape variables.