[Bug 9874] New: Adding subfield «ampersand» produce unexpected behaviours
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 Bug ID: 9874 Summary: Adding subfield «ampersand» produce unexpected behaviours Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt@gmail.com Reporter: pablo.bianchi@gmail.com 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? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|3.10 |master CC| |katrin.fischer@bsz-bw.de -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@biblibre.co | |m Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Jonathan Druart <jonathan.druart@biblibre.com> --- 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). -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 Pablo AB <pablo.bianchi@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED --- Comment #2 from Pablo AB <pablo.bianchi@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 --- Comment #3 from Pablo AB <pablo.bianchi@gmail.com> --- Created attachment 37642 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=37642&action=edit Screenshot of what it happens if you tried to open a non-escaped character -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 --- Comment #4 from Pablo AB <pablo.bianchi@gmail.com> --- Created attachment 37643 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=37643&action=edit Screenshot after trying to delete such subfields. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 --- Comment #5 from Jonathan Druart <jonathan.druart@biblibre.com> --- (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 '&'. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 --- Comment #6 from Jonathan Druart <jonathan.druart@biblibre.com> --- But... why do you want to use this character? :) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9874 --- Comment #7 from Pablo AB <pablo.bianchi@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org