https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20307
Julian Maurice <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Status|Signed Off |Failed QA --- Comment #96 from Julian Maurice <[email protected]> --- A few complaints from QA script: FAIL Koha/Schema/Result/AuthorisedValueLocalization.pm FAIL pod coverage POD coverage was greater before, try perl -MPod::Coverage=PackageName -e666 FAIL installer/data/mysql/atomicupdate/bug_20307.sql FAIL git manipulation The file has been added and deleted in the same patchset So, maybe patches should be squashed. Also: 1) The value stored in localization.code is a concatenation of the AV category code, a '_', and the AV code. Which means that if we have a category A with a value B_C, and a category A_B with a value C, they will share their translations. 2) It feels weird to have the ability to translate for all languages. I mean, the original description is already written in one of those languages, right ? So if I add a translation for each language, the original description will never be used. Not really a problem though, as it allows to have the original description in the language we want, and we can just not add a translation for that language. 3) There is some places where translated descriptions are not used (the items table in cataloguing/additem.pl for instance) but that can be added later (not blocking) 4) The new column 'interface' will be only useful for authorized value, right ? Why not append the interface to the entity name instead of adding a new column ("authorised_values:opac" for instance) ? Actually, the AV category code could be added there too to avoid (1) ("authorised_values:opac:CCODE"). 5) Please add a test plan :) Even if it's not exhaustive it really helps to have one. 6) Koha::AuthorisedValues::search_with_localization does something really strange : it sets package variables $Koha::Schema::Result::AuthorisedValue::LANGUAGE and $Koha::Schema::Result::AuthorisedValue::INTERFACE. I understand that they are then used in the has_many subroutine for 'localization', and that the same thing is done for itemtypes, but that feels wrong to use global variables like that. Can't we use a "normal" join in search_with_localization ? And why has_many ? An authorised value should have only 1 (or 0) translation, given a particular language and interface. Failing QA for (1) that should be fixed, but I really would like to know your opinions on the other points -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
