github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-16 07:04:23 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #3054] [Feature] [Mobile] Improve "amount" input experience: no decimal fraction by default, allow both "." and "," sign as decimal fraction sign #27024

New Issue
Closed
opened 2026-04-18 03:26:00 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-18 03:26:00 -05:00
Owner
Copy Link

Originally created by @andriantoeff on GitHub (Jul 14, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/3054

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

My background/my bias/my expectations:

  • I am from a country with a high number of digits in its currency system (1 digit in USD translates to 5-6 digits in my country). I mostly enter whole numbers (some thousands or some millions) for my transactions with some few exceptions. I still want to have the ability to enter fractional digits for precision tracking (particularly for interest amounts and discounted amounts).
  • I have experience with another financial-tracking app that I used for a while, with a thousand separator and decimal separator handling that I like.

Current experience:

  1. In mobile view, adding/editing transaction's amount force the user to a numeric-input mode, with a numeric soft-keypad that automatically appears.
  2. When not using "Hide decimal places", the first numbers the user input will be considered as the last fractional digit (of a 2 fractional digits allowed), and subsequent numbers will push the numbers to the left, just like a calculator, but with a fixed decimal point in-place.
  3. When using "Hide decimal places", the user cannot enter a fractional amount at all, whether in editing mode nor in the adding transaction mode.
  4. The field does not intuitively/does not designed to allow copy-pasted value, though there can be a workaround to force a paste. (This is not a complain.)
  5. Deleting the amount sometimes can make the field empty and make the field height nearly zero.

Describe your ideal solution to this problem

In mobile view:

  • When using "Hide decimal places", fraction values should still be allowed to be entered when the user deliberately keyed in the decimal sign.
  • When NOT USING "Hide decimal places", fraction values should not be entered automatically unless the user deliberately keyed in the decimal sign. e.g. When the user keyed in 4, 5, 6, it should be recognized as "456.00" in contrast to the current behavior (currently recognized as "4.56").
  • When focusing on the amount field (in add/edit mode): remove thousand separator formatting and just use the (configured) decimal sign; do not allow entering thousand separator signs; also skip thousand separator signs from pasted values. The purpose is that the user can be sure that the sign that is present in the active field must be a decimal sign.
  • With the thousand separator blocked from being keyed-in, allow both "," and "." in the keypad to be used as decimal separator, and convert it instantly as the configured decimal separator sign when keyed in; but do not honor this behavior when parsing a pasted amount if it is possible to differentiate the input source.
  • Releasing the focus from the amount field (in add/edit mode) should immediately: reformat the amount to the configured separator signs; ignore the "Hide decimal places" config and keep displaying the decimal fraction up to a limit that is in-sync with what will be saved in the database; round as necessary if the database digit limit will change the entered fraction value. e.g. 1234567.8 may be reformatted to "1,234,567.80"; 12.30000009 may be reformatted to "12.30".
  • Going out of the add/edit mode is when the "Hide decimal places" is honored.
  • Also, when adding/editing, fallback to "0.00" amount when the field is somehow empty.

Teaching and learning

This should be the default UX in mobile view.

Originally created by @andriantoeff on GitHub (Jul 14, 2024). Original GitHub issue: https://github.com/actualbudget/actual/issues/3054 ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [X] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? #### My background/my bias/my expectations: - I am from a country with a high number of digits in its currency system (1 digit in USD translates to 5-6 digits in my country). I mostly enter whole numbers (some thousands or some millions) for my transactions with some few exceptions. I still want to have the ability to enter fractional digits for precision tracking (particularly for interest amounts and discounted amounts). - I have experience with another financial-tracking app that I used for a while, with a thousand separator and decimal separator handling that I like. #### Current experience: 1. In mobile view, adding/editing transaction's amount force the user to a numeric-input mode, with a numeric soft-keypad that automatically appears. 2. When *not using* "Hide decimal places", the first numbers the user input will be considered as the last fractional digit (of a 2 fractional digits allowed), and subsequent numbers will push the numbers to the left, just like a calculator, but with a fixed decimal point in-place. 3. When *using* "Hide decimal places", the user cannot enter a fractional amount at all, whether in editing mode nor in the adding transaction mode. 4. The field does not intuitively/does not designed to allow copy-pasted value, though there can be a workaround to force a paste. (This is not a complain.) 5. Deleting the amount sometimes can make the field empty and make the field height nearly zero. ### Describe your ideal solution to this problem In mobile view: - When using "Hide decimal places", fraction values should still be allowed to be entered when the user deliberately keyed in the decimal sign. - When NOT USING "Hide decimal places", fraction values should not be entered automatically unless the user deliberately keyed in the decimal sign. e.g. When the user keyed in 4, 5, 6, it should be recognized as "456.00" in contrast to the current behavior (currently recognized as "4.56"). - When focusing on the amount field (in add/edit mode): remove thousand separator formatting and just use the (configured) decimal sign; do not allow entering thousand separator signs; also skip thousand separator signs from pasted values. The purpose is that the user can be sure that the sign that is present in the active field must be a decimal sign. - With the thousand separator blocked from being keyed-in, allow both "," and "." in the keypad to be used as decimal separator, and convert it instantly as the configured decimal separator sign when keyed in; but do not honor this behavior when parsing a pasted amount if it is possible to differentiate the input source. - Releasing the focus from the amount field (in add/edit mode) should immediately: reformat the amount to the configured separator signs; ignore the "Hide decimal places" config and keep displaying the decimal fraction up to a limit that is in-sync with what will be saved in the database; round as necessary if the database digit limit will change the entered fraction value. e.g. 1234567.8 may be reformatted to "1,234,567.80"; 12.30000009 may be reformatted to "12.30". - Going out of the add/edit mode is when the "Hide decimal places" is honored. - Also, when adding/editing, fallback to "0.00" amount when the field is somehow empty. ### Teaching and learning This should be the default UX in mobile view.
GiteaMirror added the needs votesfeature labels 2026-04-18 03:26:00 -05:00
GiteaMirror commented 2026-04-18 03:26:02 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 14, 2024):

✨ Thanks for sharing your idea! ✨

This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

<!-- gh-comment-id:2227393835 --> @github-actions[bot] commented on GitHub (Jul 14, 2024): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don’t forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
GiteaMirror commented 2026-04-18 03:26:02 -05:00
Author
Owner
Copy Link

@andriantoeff commented on GitHub (Jul 21, 2024):

Changing the current "auto decimal" behavior will be difficult because apparently this is a requested1 behavior and is a default behavior in YNAB.

This "auto decimal" behavior may not be a standard across different apps2 , and can be a source of mistake3 . So there can still be room to change the default behavior.

However, I understand that a huge slice of Actual users may come from YNAB, and pushing for the change will be met with a lot of resistance.

With these findings, I will take time to rethink the scope, goal, and steps for this feature request. Any input is appreciated.

<!-- gh-comment-id:2241481037 --> @andriantoeff commented on GitHub (Jul 21, 2024): Changing the current "auto decimal" behavior will be difficult because apparently this is a requested[^1] behavior and is a default behavior in YNAB. This "auto decimal" behavior may not be a standard across different apps[^2], and can be a source of mistake[^3]. So there can still be room to change the default behavior. However, I understand that a huge slice of Actual users may come from YNAB, and pushing for the change will be met with a lot of resistance. With these findings, I will take time to rethink the scope, goal, and steps for this feature request. Any input is appreciated. [^1]: Feature request: #1509 & PR: #2536 [^2]: [Reddit: Change YNAB number input method](https://www.reddit.com/r/ynab/comments/151yo2h/change_ynab_number_input_method/) [^3]: [Reddit: I love the fixed decimal point in YNAB app... however](https://www.reddit.com/r/ynab/comments/cyhrkp/i_love_the_fixed_decimal_point_in_ynab_app_however/)
GiteaMirror commented 2026-04-18 03:26:02 -05:00
Author
Owner
Copy Link

@andriantoeff commented on GitHub (Dec 9, 2024):

An idea to make it work with "auto decimal" behavior still in place: pressing comma/dot will "auto-advance" number input to the after-comma position.

After the first comma/dot input, subsequent commas/dots will be ignored.

After the first comma/dot input, subsequent numbers will only lengthen the decimal post-comma's precision. How many decimal precisions can be taken in the UI will be up to the UI logic and may be outside of the scope of this change.

Example (with "auto decimal" behavior + suggested changes):

  1. Input: 5 3 1 → 5.31
  2. Input: , → 531.00
  3. Input: 5 5 5 5 5 5 → 531.555555 (if the UI allows this many decimal precision)
  4. How many decimal precisions stored in DB will be up to the DB column spec and global application rule/logic. In 4 digits precision mode, it may be stored as 531.5556 due to rounding.
<!-- gh-comment-id:2526752321 --> @andriantoeff commented on GitHub (Dec 9, 2024): An idea to make it work with "auto decimal" behavior still in place: pressing comma/dot will "auto-advance" number input to the after-comma position. After the first comma/dot input, subsequent commas/dots will be ignored. After the first comma/dot input, subsequent numbers will only lengthen the decimal post-comma's precision. How many decimal precisions can be taken in the UI will be up to the UI logic and _may be_ outside of the scope of this change. Example (with "auto decimal" behavior + suggested changes): 1. Input: 5 3 1 → `5.31` 2. Input: , → `531.00` 3. Input: 5 5 5 5 5 5 → `531.555555` (if the UI allows this many decimal precision) 4. How many decimal precisions stored in DB will be up to the DB column spec and global application rule/logic. In 4 digits precision mode, it may be stored as `531.5556` due to rounding.
GiteaMirror commented 2026-04-18 03:26:02 -05:00
Author
Owner
Copy Link

@andriantoeff commented on GitHub (Dec 9, 2024):

Progress note: I haven't made the time to explore the code changes required to make this work. So this change is still free to grab.

<!-- gh-comment-id:2526755444 --> @andriantoeff commented on GitHub (Dec 9, 2024): Progress note: I haven't made the time to explore the code changes required to make this work. So this change is still free to grab.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature needs votes
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#27024
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?