mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-16 07:04:23 -05:00
[GH-ISSUE #4896] [Bug]: Random hidden category being applied to manual transactions #51200
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#51200
Reference in New Issue
Block a user
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?
Originally created by @officeboy on GitHub (Apr 28, 2025).
Original GitHub issue: https://github.com/actualbudget/actual/issues/4896
Verified issue does not already exist?
What happened?
When entering manual transactions on desktop in chrome or the MS store app random categories are being assigned AFTER moving to a new screen. I can check them over after entering and they are fine, but will go to the budget screen and then it will show next month is underbudget due to wrong categories being assigned.
How can we reproduce the issue?
Enter a string of manual transactions, Not sure if it has to do with the size of my data? It's 11 years of Ynab imported into Actual. Additionally it seems to happen more often on new or infrequently used Payees
Where are you hosting Actual?
Docker
What browsers are you seeing the problem on?
Chrome
Operating System
Windows 11
@youngcw commented on GitHub (Apr 28, 2025):
check your rules for one that is setting the category to the hidden one
@officeboy commented on GitHub (Apr 28, 2025):
Thank you, I have already checked and deleted all of the rules that reference any of my past hidden categories. The issue has continued. Additionally no rules should have been matched the last two times it happened.
@youngcw commented on GitHub (Apr 30, 2025):
One more option would be to make an export, then delete all rules in the export and see if its still happens. I don't know what to try without having the file.
@officeboy commented on GitHub (Apr 30, 2025):
I am also wonder if the format of the categories has a bearing. They are all formatted as Master Category/Category (ie Savings Goals/New Car). Are there logs I can review or share next time it happens?
@alecbakholdin commented on GitHub (May 3, 2025):
@officeboy you can try to check your browser logs with ctrl + shift + i or f12 (go to the console tab) if it happens in the browser. There's a chance that there might be something there but I'm not super hopeful. This seems like a value is slow to clear from state somewhere
@officeboy commented on GitHub (May 8, 2025):
Was able to reproduce it! I am used to typing in a partial value and once it matches hitting tab to move to the next field. These seems to use a different match than is displayed. In the attached screen vid I use tab twice, and then I use enter and then tab.
https://github.com/user-attachments/assets/2536dd2c-f377-4179-b665-855406d21fa5
At this point I'm not sure if the bug is that a hidden category can be selected, or if it's just that the matching has a problem.
@youngcw commented on GitHub (May 13, 2025):
So it seems the issue is less that its applying a hidden category and more that its not applying the category that was shown. Im guessing that if you changed the name of the hidden category to not match the non-hidden one's first few letters the issue wouldn't happen.
@officeboy commented on GitHub (May 13, 2025):
Matching is one reason I chose this example (I had 3 to pick from that day). The first letters I was selecting were HOU which do not match the first 3 letters in the selection (HOM), but do match at the end in the word "Greenhouse".
@youngcw commented on GitHub (Jun 4, 2025):
Ive run into this a few times. It maybe only happens if you quickly type and choose the category.
@officeboy commented on GitHub (Jun 4, 2025):
It seems to happen when I use tab to move to the next field. It seems to select the match from the end of the word (Partial character match from end to front of the category).
I'm pretty sure it's here and judging from the notes not a simple fix.
f9f6917fcd/packages/desktop-client/src/components/autocomplete/Autocomplete.tsx (L304-L618)@officeboy commented on GitHub (Jun 4, 2025):
Wonder what turning line 508 into this would do.
if (e.key === 'Enter' || e.key === 'Tab') {f9f6917fcd/packages/desktop-client/src/components/autocomplete/Autocomplete.tsx (L508)@youngcw commented on GitHub (Jun 4, 2025):
My guess is that its whatever list entry was first, just that it might have been hidden. That first entry might have matched on the end of the name, but thats not what I was seeing. I was seeing beginning match, just it was first in the list