http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10855 --- Comment #75 from Jonathan Druart <jonathan.druart@biblibre.com> --- (In reply to Jacek Ablewicz from comment #74)
Hello Jonathan,
Hello Jacek,
1) Methods in Koha/AdditionalField.pm are taking 'tablename' as an argument, but they are occasionally called with 'table' instead (in patch 22700/Search.pm, 22699/serials-search.pl, 22698, ..) which is silently ignored by package methods. This problem is only starting to manifest itself if there are additional fields for 2+ different tables being used.
Good catch, I will provide a followup.
2) Column 'value' in table additional_field_values is created (patch 22703) with utf8_bin collation (but only in installer/data/mysql/updatedatabase.pl, not in the installer/data/mysql/kohastructure.sql ?). I wonder if this is intentional (to make it case-sensitve)?
No, patch coming...
3) Any chances to support/allow arbitrary field names (with non-ascii characters, spaces etc.)? That will probably require an extra column (e.g. "label") in additional_fields table (?).
Why? There are a free field and an id, I thought it was enough.
4) If there are non-asci / uft-8 characters involved (anywhere in the objects returned from AdditionalField.pm - in cases when offending objects are further processed with C4::Templates->output), result WWW page is prone to be garbled (partially double-encoded). This problem is similar to bug 11290; it happens because output()/utf8_arrayref()/utf8_hashref() in Templates.pm do not know what to do with blessed hashrefs - if ref() doesn't return HASH or ARRAY, they wrongly assume it's a scalar.. Like for bug 11290, adding bunch of ' |html_entity' to templates does work as an workaround for this problem, but I'm wondering if we shouldn't actually fix Templates.pm instead, that would be better/more general solution (?).
Yes, I think we must have a generic solution here, not fixing templates. I submitted a patch on bug 6554. -- You are receiving this mail because: You are watching all bug changes.