Update number type to support custom currency format

[ghislaineguerin]

Fixes mathesar-foundation/mathesar#1063

[silentninja]

Based on our discussion on Matrix, we should have the UX in such a way that Postgres Money type is discouraged, since it does not bring any advantage over the numeric type + display options, rather has limitations

[kgodey]

@ghislaineguerin This spec does not address this design problem from mathesar-foundation/mathesar#1063

Users may be confused by two different types to represent money (Money, and Number + display options). We should figure out how to represent this to the user in a way that's easy to understand.

From @pavish in the Matrix discussion about this topic:

If a non-technical user wants to add a money column, how will they know which to use? We provide two separate options, they might add one wrongly or might want to switch from one to another, in which case the display options of number (eg., choosing currency symbol) will be lost.

Their first instinct will be to go to the Money type, and we could have limitations and warnings there, but how do we get the message across that it's a database issue and they'll have to tweak db config, especially considering that they're non-technical.

We would like them to use the display settings of Number, but our UX shows Money more prominently and display options are hidden.

It is a guarantee that the user will always go to the Money type, and how do we redirect it effectively?

[kgodey]

Potential solutions, not all of these are mutually exclusive.

• Display money type as "Dollars" (or whatever the locale is set to)
• Show a warning message when using Money type that we recommend that users use the Number type with currency formatting instead
• Create a custom "money" type that's actually just a alias for NUMERIC and will need display options set to be useful. Move currency formatting options there.
• Don't allow users to change column type to the Money type, only show the Money type if there's an existing column that uses it.

Other solutions proposed were:

• Remove currency formatting from number types entirely (this is not an option since we still need a way for users to store columns with different currencies)
• Remove support for Money type entirely (this seems unwise since we want to support all default Postgres types)

[kgodey]

Please see my comments on the main thread.

[mathemancer]

Remove support for Money type entirely (this seems unwise since we want to support all default Postgres types)

A middle ground would be to keep support, but make the PostgreSQL Money type an "other" type in the UI. That would discourage users, and give them the expectation that it's not strongly supported, but we wouldn't have to remove any functionality that we currently have.

[kgodey]

A middle ground would be to keep support, but make the PostgreSQL Money type an "other" type in the UI. That would discourage users, and give them the expectation that it's not strongly supported, but we wouldn't have to remove any functionality that we currently have.

We aren't offering any special display or editing functionality for "other" types. Since we'll already be building in display/editing functionality for working with money, it seems counterintuitive to not offer it for PostgreSQL Money type columns by relegating them to "other".

[kgodey]

Looks good @ghislaineguerin, some minor changes requested.

[kgodey]

The warning should say:

"The currency setting of this database type cannot be changed."

If the custom Money type is available, it should say:

To use a different currency, please change this type to Number and back to Money.

If the custom Money type is not available, it should say:

Please contact an administrator if you'd like to change the currency setting.

The frontend will know whether the custom Money type is available, so it can use the appropriate message depending on the availability.

[ghislaineguerin]

This has been updated.

[kgodey]

Looks good to me. The only change I'd like is to change the "Symbol Location" options to Beginning and End, I think it's clearer.

@pavish Can you take a look and make sure this works for frontend formatting?

[pavish]

The options look good, it would suffice for frontend formatting.

The number of inputs is many for the display options, it will definitely exceed the window size. We'll need a scrollbar in this pane or change the width for the dropdown. The max-height needs to be fixed.

@ghislaineguerin It would be better to have a prototype with scrollbars.

[ghislaineguerin]

This has been updated.

[kgodey]

@ghislaineguerin I don't see a scrollbar in the prototype.

[kgodey]

These don't seem to match what's in the prototype.

[ghislaineguerin]

I've fixed this to match the prototype.

[kgodey]

@ghislaineguerin Looks good, the only comment is that I don't see a scrollbar in the prototype (per @pavish's comment).

[ghislaineguerin]

@kgodey I have added the scrollbars. I will merge this since that was the only change requested.