Summary: | Adding subfield «ampersand» produce unexpected behaviours | ||
---|---|---|---|
Product: | Koha | Reporter: | Pablo AB <pablo.bianchi> |
Component: | MARC Bibliographic data support | Assignee: | 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
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). 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. Created attachment 37642 [details]
Screenshot of what it happens if you tried to open a non-escaped character
Created attachment 37643 [details]
Screenshot after trying to delete such subfields.
(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 '&'. But... why do you want to use this character? :) 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. This appears to have been fixed, presumably via the extensive work we've done to properly escape variables. |