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

[GH-ISSUE #8078] [Bug]: Payee and category autocomplete search are case-sensitive #117666

New Issue
Closed
opened 2026-06-11 13:07:01 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-06-11 13:07:01 -05:00
Owner
Copy Link

Originally created by @jdcorona96 on GitHub (Jun 4, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/8078

What happened?

When creating or editing a transaction, the payee and category autocomplete search becomes case-sensitive as soon as any uppercase letter is typed.

What I was trying to create or edit a transaction, I typed in the Payee and Category fields to search for existing entries.

I expected the search return matching results regardless of how I capitalize my input — typing rest, Rest, or REST should all show "Restaurants".

But when I add any uppercase letter, the search becomes case-sensitive and only returns results that match the exact casing. For example, typing 'rest' works fine, but 'Rest' or REST returns no results unless the stored name matches that exact casing.

no other effects in the other search areas in the app — rules, schedules, tags, and transaction. They all work correctly. Only transaction payee/category autocomplete affected.

Root cause identified

This regression was introduced in v26.6.0 by PR #7261, which replaced the previous substring-based filter with the fzf fuzzy search library. The fzf library defaults to casing: "smart-case", which means:

all-lowercase input → case-insensitive search ✅
any uppercase character in input → case-sensitive search ❌

This seems intentional, but it produces confusing and broken results for me and possibly for others, especially for phone users. some keyboards automatically capitalizes the first letter of the sentence/word, removing a lot of options for people who didn't capitalize their payees or categories.

How can we reproduce the issue?

  1. On any account, click to add or edit a transaction
    a. phone users: select on 'transaction'
  2. select the Payee or Category field
  3. Type a search term that matches an existing entry using any uppercase letter (e.g. Rest for "Restaurants")
    • (phone automatically capitalizes first letter) Amazon for "amazon"
  4. Observe that the filtered results

Expected: results appear regardless of casing
Actual: results disappear as soon as any uppercase letter is typed (no result for "amazon")

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Safari

Operating System

Mac OSX

Originally created by @jdcorona96 on GitHub (Jun 4, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/8078 ### What happened? When creating or editing a transaction, the payee and category autocomplete search becomes case-sensitive as soon as any uppercase letter is typed. What I was trying to create or edit a transaction, I typed in the `Payee` and `Category` fields to search for existing entries. I expected the search return matching results regardless of how I capitalize my input — typing rest, Rest, or REST should all show "Restaurants". But when I add any uppercase letter, the search becomes case-sensitive and only returns results that match the exact casing. For example, typing 'rest' works fine, but 'Rest' or REST returns no results unless the stored name matches that exact casing. no other effects in the other search areas in the app — rules, schedules, tags, and transaction. They all work correctly. Only transaction payee/category autocomplete affected. --- Root cause identified This regression was introduced in v26.6.0 by PR #7261, which replaced the previous substring-based filter with the fzf fuzzy search library. The fzf library defaults to casing: "smart-case", which means: all-lowercase input → case-insensitive search ✅ any uppercase character in input → case-sensitive search ❌ This seems intentional, but it produces confusing and broken results for me and possibly for others, especially for phone users. some keyboards automatically capitalizes the first letter of the sentence/word, removing a lot of options for people who didn't capitalize their payees or categories. ### How can we reproduce the issue? 1. On any account, click to add or edit a transaction a. phone users: select on 'transaction' 3. select the Payee or Category field 4. Type a search term that matches an existing entry using any uppercase letter (e.g. Rest for "Restaurants") - (phone automatically capitalizes first letter) Amazon for "amazon" 6. Observe that the filtered results Expected: results appear regardless of casing Actual: results disappear as soon as any uppercase letter is typed (no result for "amazon") ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Safari ### Operating System Mac OSX
GiteaMirror added the buguser interfacegood first issue labels 2026-06-11 13:07:02 -05:00
GiteaMirror commented 2026-06-11 13:07:05 -05:00
Author
Owner
Copy Link

@coderabbitai[bot] commented on GitHub (Jun 4, 2026):

🔗 Related PRs

actualbudget/actual#7261 - [AI] Replace payee and category autocomplete filter/sort with fzf fuzy search [merged]

📝 Issue Planner

Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.

  • Create Plan
🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

<!-- gh-comment-id:4620711666 --> @coderabbitai[bot] commented on GitHub (Jun 4, 2026): <!-- This is an auto-generated issue plan by CodeRabbit --> <details> <summary>🔗 Related PRs</summary> actualbudget/actual#7261 - [AI] Replace payee and category autocomplete filter/sort with fzf fuzy search [merged] </details> --- <details> <summary>📝 Issue Planner</summary> <sub>Check the box below or use the `@coderabbitai plan` command to generate an implementation plan and prompts that you can use with your favorite coding assistant.</sub> - [ ] <!-- {"checkboxId": "8d4f2b9c-3e1a-4f7c-a9b2-d5e8f1c4a7b9"} --> Create Plan </details> --- <details> <summary> 🧪 Issue enrichment is currently in open beta.</summary> You can configure auto-planning by selecting labels in the issue_enrichment configuration. To disable automatic issue enrichment, add the following to your `.coderabbit.yaml`: ```yaml issue_enrichment: auto_enrich: enabled: false ``` </details> 💬 Have feedback or questions? Drop into our [discord](https://discord.gg/coderabbit)!
GiteaMirror commented 2026-06-11 13:07:05 -05:00
Author
Owner
Copy Link

@jdcorona96 commented on GitHub (Jun 4, 2026):

including PR

#8079

<!-- gh-comment-id:4620803521 --> @jdcorona96 commented on GitHub (Jun 4, 2026): including PR #8079
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 bug good first issue user interface
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#117666
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?