Bug 9874

Summary: Adding subfield «ampersand» produce unexpected behaviours
Product: Koha Reporter: Pablo AB <pablo.bianchi>
Component: MARC Bibliographic data supportAssignee: Galen Charlton <gmcharlt>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P5 - low CC: jonathan.druart
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Attachments: Screenshot of what it happens if you tried to open a non-escaped character
Screenshot after trying to delete such subfields.

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=&amp;
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.