mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-15 22:54:03 -05:00
[GH-ISSUE #1615] [Bug]: Category autocomplete - filter search matches on category group names #42264
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#42264
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 @trevdor on GitHub (Aug 31, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/1615
Verified issue does not already exist?
What happened?
Transactions table category autocomplete matches your search term against category group names, which are not selectable. If there are many categories in the matching group, the desired category may not even be visible for a mouse click. Personally, I don't think a mouse click should be necessary, as Actual is all about optimizing speed of transaction entry.
My real-world example: category group
Active Expensesgets matched when I search for myActivitiescategory until I get to the secondi.Workaround
Make sure your category group names share little in common with your category names.
Maybe not a bug?
It's working as built, and I could easily understand the argument not to change an existing behavior when it's so easy to work around. Plus, it's possible some folks prefer to find
Billsin the above example and then click the category. 🤷🏻♂️I'd lean on my staying-on-the-keyboard-is-faster argument here. Also, I suspect most people get to know their category names relatively well, and don't try to find by group name. But just a guess.
@trevdor commented on GitHub (Aug 31, 2023):
@Kidglove57 @joel-jeremy @MatissJanis @shall0pass
Could a couple of you confirm or challenge my classification of this as a bug, please?
@Kidglove57 commented on GitHub (Aug 31, 2023):
Whilst this behaviour has never given me any difficulties (and I had not given it a second thought before), I agree that there is an very good argument for category groups to be excluded from the search/filter. I cannot see any situation, in this particular context, where I would be looking for the group name. As you say, they are not selectable.
PS: I have over 60 categories so the chance of some partial duplication of names does increase.
@MatissJanis commented on GitHub (Sep 1, 2023):
I share @Kidglove57 sentiment. Excluding category groups IMO makes sense.
@doggan commented on GitHub (Sep 5, 2023):
I just stumbled on Actual for setting up my own budget after being a YNAB user for many years, so forgive me if this isn't the right place to post this :)
I'd vote against this change. It can be really useful as-is for certain groupings. For example, I often type "inc" when categorizing to bring up the income categories. The current behavior is also how it works in YNAB:
The "which are not selectable" point in the original comment is valid though. YNAB handles this by shrinking the text size of the category group names, as you can see in the above screenshot. Maybe this Issue could be modified to be a UX change (shrinking the category group name text) instead of a functionality change, such that it's clear the category group names are no selectable.
@Kidglove57 commented on GitHub (Sep 5, 2023):
I find this a really helpful perspective - thank you. It does not worry me in the least that the category groups should still appear in the filter and your point about the Income group resonated with me, as that is the group where I am least likely to remember some less used category names.
@kennylarsen commented on GitHub (Sep 7, 2023):
I just discovered this. I think my preference would be for the search to focus on the categories themselves, but still display the groups in the list.
@shaankhosla commented on GitHub (Sep 9, 2023):
I agree that the search should focus on the categories but display the groups. I'm new to the codebase but happy to try and tackle this
@shaankhosla commented on GitHub (Sep 9, 2023):
Looking at the code, this is a super easy change. I'll open a pull request and then we can decide if we want to merge it in
@shall0pass commented on GitHub (Sep 13, 2023):
I've been back and forth on this, but I think I favor the proposed change. I also don't search by category group and have gotten to know my category names really well. I do empathize with @doggan on the point being made. While this change will be welcomed by some, it may be unwelcome by others. It all comes down to how each of our typical workflows vary.
The one example in my workflow would be adding a transaction to my mobile phone category. If I search for 'mo', I get all of my 'Monthly Cash Expenses' and 'Monthly Bills' category groups first. It isn't until 'mob' that it starts to narrow down enough to be useful, which I realize is just 1 letter.