The database field currency.currency is defined as VARCHAR(10) NOT NULL. This needs to be increased e.g. set as VARCHAR(255) NOT NULL. The rationale: a) While it is possible to accomodate 'US Dollar' in that width, for many currencies this space is inadequate e.g. 'East Caribbean Dollar', 'Indian Rupee' or 'Tanzanian Shilling'. b) Further, in the 'New currency' addition form, the maxlength and size attributes are set as 50, and allows user to enter long names as examples above. While saving the record, it is truncated to VARCHAR(10). I propose the following: 1/ Alter the currency.currency field to VARCHAR(255) NOT NULL from VARCHAR(10) NOT NULL. 2/ Change the 'maxlength' attribute in the template to 255 (to match column property)
Created attachment 39021 [details] [review] Bug 14179 - Alters currency field to VARCHAR(255) Alters `currency`.`currency` column from VARCHAR(10) to VARCHAR(255)
Created attachment 39022 [details] [review] Bug 14179 - Update currency field's maxlength attribute Updates 'maxlength' attribute of field 'currency' in the 'New currency' addition form to 255 and brings it in sync with the field width of corresponding `currency`.`currency` column.
Test plan (for attachment 39021 [details] [review]) ================================ 1/ login to Koha staff client and go to Home -> Administration -> Currencies & Exchange rates 2/ add a new currency - Bhutanese Ngultrum, ISO code BTN, currency symbol Nu. and rate of 0.016) and save it. 3/ the currency name should be truncated as 'Bhutanese ' 4/ apply the patch in attachment 39021 [details] [review] 5/ update the db schema by running : % perl installer/data/mysql/updatedatabase.pl 6/ delete currency 'Bhutanese ' 7/ repeat step #2 above 8/ the currency should be saved correctly (without truncation)
Test plan for attachment 39022 [details] [review] ============================== 1/ login to Koha staff client and go to Home -> Administration -> Currencies & Exchange rates 2/ try to enter a 59 character long fictitious currency name e.g. 'very long imaginary currency name from a fictitious country' 3/ you shouldn't be able to enter more than 'very long imaginary currency name from a fictitiou' (50 characters). do not try to save the record. 4/ apply the patch in attachment 39022 [details] [review] 5/ repeat step #2 6/ you should be able to save the entire 59 char long name
Created attachment 39030 [details] [review] Bug 14179 - Alters currency field to VARCHAR(255) Alters `currency`.`currency` column from VARCHAR(10) to VARCHAR(255) Test plan ========= 1/ login to Koha staff client and go to Home -> Administration -> Currencies & Exchange rates 2/ add a new currency - Bhutanese Ngultrum, ISO code BTN, currency symbol Nu. and rate of 0.016) and save it. 3/ the currency name should be truncated as 'Bhutanese ' 4/ apply the patch in attachment 39021 [details] [review] [review] 5/ update the db schema by running : % perl installer/data/mysql/updatedatabase.pl 6/ delete currency 'Bhutanese ' 7/ repeat step #2 above 8/ the currency should be saved correctly (without truncation)
Created attachment 39031 [details] [review] Bug 14179 - Alters currency field to VARCHAR(255) Alters `currency`.`currency` column from VARCHAR(10) to VARCHAR(255) Test plan ========= 1/ login to Koha staff client and go to Home -> Administration -> Currencies & Exchange rates 2/ add a new currency - Bhutanese Ngultrum, ISO code BTN, currency symbol Nu. and rate of 0.016) and save it. 3/ the currency name should be truncated as 'Bhutanese ' 4/ apply the patch 5/ update the db schema by running : % perl installer/data/mysql/updatedatabase.pl 6/ delete currency 'Bhutanese ' 7/ repeat step #2 above 8/ the currency should be saved correctly (without truncation)
I believe the problem of a currency description is in need of a new table, not an increased field width. The currency column is used as a CODE not as a DESCRIPTION, as you are assuming.
(In reply to M. Tompsett from comment #7) > I believe the problem of a currency description is in need of a new table, > not an increased field width. The currency column is used as a CODE not as a > DESCRIPTION, as you are assuming. That be the case, giving it a maxlength and size of 50 is highly misleading. No?
(In reply to Indranil Das Gupta from comment #8) > (In reply to M. Tompsett from comment #7) > > I believe the problem of a currency description is in need of a new table, > > not an increased field width. The currency column is used as a CODE not as a > > DESCRIPTION, as you are assuming. > > That be the case, giving it a maxlength and size of 50 is highly misleading. > No? I stand corrected. There is a column ISO code for that. Though, I protest that schema.koha-community.org failed me. ;) Sadly, my iso codes are all null. Please fix that too in this. ;) Oh, and display the ISO code too. :)
(In reply to M. Tompsett from comment #9) This is what lead me to originally write the patch From bug 9593, comment 46 : "Moreover, an 'isocode' column had been added in currency table (editable in the pro interface from Administration/Currencies and exchange rates). So the active currency can be picked either through its symbol or through its iso code." From bug 9593, comment 68 : "I agree, the default data convention is for the "Currency" field to be the ISO code. However, that doesn't mean that everyone is currently following this convention. I *don't* think this is a blocker. I could easily see the Currency being "Brazilian real" while the ISO code would be "BRL". Since not everyone memorizes ISO codes for currency, I think this may be an improvement anyway." and then Galen pointing out in bug 9593, comment 76 : "Note that currency.currency is only a varchar(10)."
Added bug 11939, since I posted a nice little script I wrote there. Perhaps you might like it. ;)
If I type something more than 255 characters, I get no warnings. I lost the first part of my currency description for something over 255 characters. Is there a way to wrap long descriptions, because my 255 character descriptions make the table impractical to use. I find it strange the description can not be edited. Why? AH! Because of the relationships into aqbooksellers invoiceprice and listprice. Perhaps you need another bug to fix the relation to be on the ISO code, and then this one to fix the width. Because you can't change the width to 255 on this related field.
In my experience sites using multiple currencies use the 3 character international code, (acquisitions librarians often seem to use these exclusively) As they are unambigious and required for most ordering scenarios using these as primary key would make more sense. And more verbose descriptions really belong in a text field. Looking at a number of sites I see these in the currency field and the isocpde field unused. In fact many people use them in the role of symbol as well ($ is ambiguous after all). It might be worth reviewing the table's usage more fully
(In reply to Colin Campbell from comment #13) > It might be worth reviewing the table's usage more fully Not just the table, but the whole currency mess. It seems that this thread (I have a long description that I want to use), pulls that thread (related to other tables on a description field?!), pulls another thread (what about history?), pulls another (why are currency functions in C4::Acquisition, and not a specific currency library?), etc.
<Bug wrangling> Did anything come of this? I see the currency table in the current master is still pretty much the same, with the currency.currency field still varchar(10) and the new currency addition input field size set to 50. At the very least, could we get the field size set to 10 so that people don't lose long currency names?
(In reply to Jon Knight from comment #15) > <Bug wrangling> > > Did anything come of this? I see the currency table in the current master is > still pretty much the same, with the currency.currency field still > varchar(10) and the new currency addition input field size set to 50. > > At the very least, could we get the field size set to 10 so that people > don't lose long currency names? Agreed. Also: changing the field width in currency would not be enough: we'd also need to update where the field is referenced in other tables, including aqorders and aqbooksellers.