Bug 14179 - Field width for currency is wrong in the GUI
Summary: Field width for currency is wrong in the GUI
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Database (show other bugs)
Version: master
Hardware: All All
: P4 minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords: Academy
Depends on:
Blocks:
 
Reported: 2015-05-10 22:16 UTC by Indranil Das Gupta
Modified: 2023-08-16 12:25 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 14179 - Alters currency field to VARCHAR(255) (966 bytes, patch)
2015-05-10 23:04 UTC, Indranil Das Gupta
Details | Diff | Splinter Review
Bug 14179 - Update currency field's maxlength attribute (1.43 KB, patch)
2015-05-10 23:12 UTC, Indranil Das Gupta
Details | Diff | Splinter Review
Bug 14179 - Alters currency field to VARCHAR(255) (2.14 KB, patch)
2015-05-11 00:43 UTC, Indranil Das Gupta
Details | Diff | Splinter Review
Bug 14179 - Alters currency field to VARCHAR(255) (2.11 KB, patch)
2015-05-11 00:47 UTC, Indranil Das Gupta
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Indranil Das Gupta 2015-05-10 22:16:35 UTC
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)
Comment 1 Indranil Das Gupta 2015-05-10 23:04:11 UTC Comment hidden (obsolete)
Comment 2 Indranil Das Gupta 2015-05-10 23:12:25 UTC
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.
Comment 3 Indranil Das Gupta 2015-05-10 23:46:07 UTC
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)
Comment 4 Indranil Das Gupta 2015-05-10 23:58:51 UTC
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
Comment 5 Indranil Das Gupta 2015-05-11 00:43:15 UTC Comment hidden (obsolete)
Comment 6 Indranil Das Gupta 2015-05-11 00:47:13 UTC
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)
Comment 7 Mark Tompsett 2015-05-11 00:48:50 UTC
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.
Comment 8 Indranil Das Gupta 2015-05-11 00:54:56 UTC
(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?
Comment 9 Mark Tompsett 2015-05-11 01:17:18 UTC
(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. :)
Comment 10 Indranil Das Gupta 2015-05-11 01:22:51 UTC
(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)."
Comment 11 Mark Tompsett 2015-05-11 01:24:02 UTC
Added bug 11939, since I posted a nice little script I wrote there. Perhaps you might like it. ;)
Comment 12 Mark Tompsett 2015-05-11 04:53:19 UTC
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.
Comment 13 Colin Campbell 2015-05-22 08:28:55 UTC
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
Comment 14 Mark Tompsett 2015-05-22 12:34:44 UTC
(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.
Comment 15 Jon Knight 2018-11-21 16:13:05 UTC
<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?
Comment 16 Katrin Fischer 2023-08-05 10:42:09 UTC
(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.