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?
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.