Bug: model_price field limited to 2 decimal places in investment transaction form

[HugoleDino]

Before you start (required)

General checklist

• I have removed personal / sensitive data from screenshots and logs
• I have searched existing issues and discussions to ensure this is not a duplicate issue

How are you using Sure?

• I was a paying Maybe customer (hosted version)
• I use it on PikaPod, Umbrel or similar (VPS included)
• I am a self-hosted user (local only)

Self hoster checklist

• Self hosted app commit SHA (find in user menu): [91b7905]
  • I have confirmed that my app's commit is the latest version of Sure
• Where are you hosting?
  • Render
  • Docker Compose
  • Umbrel
  • PikaPod
  • Other (please specify)

---

Bug description

The model_price field in the "Add transaction" form for an investment account is limited to a step of 0.01.

However, in real-world financial markets, asset prices (stocks, ETFs, crypto, etc.) can have more precision (commonly 3 or 4 decimal places, sometimes more).

This restriction prevents users from entering accurate transaction prices and may lead to rounding errors or incorrect portfolio tracking.

To Reproduce

1. Go to an investment account
2. Click on "Add transaction"
3. Locate the model_price input field
4. Try to enter a value with more than 2 decimal places (e.g. 123.4567)
5. Observe that the input is either rounded or blocked due to the step=0.01 constraint

Expected behavior

The model_price field should allow higher precision values.

Possible fixes:

• Remove the step restriction entirely, or
• Increase precision (e.g. step=0.0001)

This would allow users to input realistic market prices without losing accuracy.

[dosubot]

This is a known area that's been reported before — see issue #922 [1] and #907 [2] which describe the same precision limitation.

The good news is that the investment trade form was already updated in PR #89 to use step: "any" with precision: 10 for the price, quantity, and fee fields [3], and the database column was also widened from scale: 4 to scale: 10 [4]. So the main trade form should accept high-precision prices.

However, there's a potential edge case: the money_field_controller.js dynamically resets the step attribute based on currency metadata (e.g., 0.01 for EUR/USD) when the currency changes [5]. This could overwrite the step: "any" set by the form template, which might be what you're hitting.

Could you confirm which specific form you're seeing this on? Is it the "Add transaction" / "Add trade" form within an investment account, or a different entry point? That would help narrow down whether this is the money_field_controller overwrite issue or a form that hasn't been updated yet.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[HugoleDino]

Hi @jjmata,
I closed the issue a bit too quickly.
As @dosu pointed out, when changing the currency (e.g. USD → EUR), the step is reset to 0.01 instead of remaining any. This causes the precision issue. Would you mind reopening the issue?
Thanks!

[dosubot]

Thanks for flagging! To add some detail on the exact root cause and a potential fix path:

The trade form correctly sets step: "any" for the price and fee fields on initial render [1]. However, when the user changes the currency, the money_field_controller.js unconditionally overwrites the step with the currency's default [2]:

this.amountTarget.step = currency.step; // always overwrites — "any" is lost

There's also a companion issue on the same code path: toFixed(currency.default_precision) will truncate a high-precision value (e.g., 1.123456789 → 1.12) when the currency changes, so even if step is preserved, the value itself may get clipped.

A minimal fix would be to have the _money_field.html.erb partial write a data attribute (e.g., data-money-field-preserve-step="true") when an explicit step: option is passed [3], and then guard the JS assignment:

if (this.amountTarget.dataset.moneyFieldPreserveStep !== "true") {
  this.amountTarget.step = currency.step;
}

This way, standard currency fields keep their dynamic step behavior, while trade form fields that explicitly pass step: "any" retain it across currency changes.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[boul2gom]

@dosu This issue is correctly handle and fixed by the PR #1342 ?