github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-05 22:52:20 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #840] [Bug]: Can't use rules to match string fields by a Polish letter if it's at the beginning of a word #7268

New Issue
Closed
opened 2026-04-10 17:01:27 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-10 17:01:27 -05:00
Owner
Copy Link

Originally created by @Jackenmen on GitHub (Apr 2, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/840

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

I have transactions with an imported payee named "Ing Bank Śląski S.A.". I noticed that it is impossible to match them using is against that exact string and I noticed that when using contains instead, it only works as long as I match with anything that doesn't contain Ś, i.e. both "Ing Bank" and "ląski S.A." are matching fine. It seems that the rules in Actual are having trouble with matching string fields by a Polish letter if that letter is the first letter of any word in the field. I've also been able to reproduce this with the "Notes" field.

Reproduction steps:

  1. Start a fresh Actual instance.
  2. Click on "Try demo"
  3. Choose any account (i.e. "Ally Savings")
  4. Click on import.
  5. Choose this file: polish-letters-repro.csv
  6. Ensure CSV fields are properly matched, either of these configurations can be used for reproduction:
    image
    image
  7. After import, 4 transactions should be added:
    image
  8. Go to the rules page and start creating a new rule.
  9. Depending on what you chose in step 6, choose the "imported payee" or "notes" field.
  10. Use the "contains" matcher (this can be reproduced with "is" as well but you can test it more easily with "contains")
  11. Type in any single Polish letter: ĄĆĘŁŃÓŚŹŻąćęłńóśźż
  12. See only 2 transactions even though 4 should match. When you look closer, both of the matched transactions are the ones that don't start with a Polish letter:
    image

What error did you receive?

The relevant transactions do not show up.

Where are you hosting Actual?

Fly.io

What browsers are you seeing the problem on?

Chrome

Operating System

Linux

Originally created by @Jackenmen on GitHub (Apr 2, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/840 ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? I have transactions with an imported payee named "Ing Bank Śląski S.A.". I noticed that it is impossible to match them using `is` against that exact string *and* I noticed that when using `contains` instead, it only works as long as I match with anything that doesn't contain `Ś`, i.e. both "Ing Bank" and "ląski S.A." are matching fine. It seems that the rules in Actual are having trouble with matching string fields by a Polish letter *if* that letter is the first letter of any word in the field. I've also been able to reproduce this with the "Notes" field. Reproduction steps: 1. Start a fresh Actual instance. 2. Click on "Try demo" 3. Choose any account (i.e. "Ally Savings") 4. Click on import. 5. Choose this file: [polish-letters-repro.csv](https://github.com/actualbudget/actual/files/11131125/polish-letters-repro.csv) 6. Ensure CSV fields are properly matched, either of these configurations can be used for reproduction: ![image](https://user-images.githubusercontent.com/6032823/229330652-b92737db-1511-4af7-988a-245370c3f7c9.png) ![image](https://user-images.githubusercontent.com/6032823/229330666-8f098074-2d33-4842-8691-d10678bda843.png) 7. After import, 4 transactions should be added: ![image](https://user-images.githubusercontent.com/6032823/229330822-af693309-d5ab-489b-b3f3-871aff05529e.png) 8. Go to the rules page and start creating a new rule. 9. Depending on what you chose in step 6, choose the "imported payee" or "notes" field. 10. Use the "contains" matcher (this can be reproduced with "is" as well but you can test it more easily with "contains") 11. Type in any single Polish letter: `ĄĆĘŁŃÓŚŹŻąćęłńóśźż` 12. See only 2 transactions even though 4 should match. When you look closer, both of the matched transactions are the ones that don't start with a Polish letter: ![image](https://user-images.githubusercontent.com/6032823/229330869-3e9ab9c7-3340-4b3c-a4c0-c1ca0c7afbd2.png) ### What error did you receive? The relevant transactions do not show up. ### Where are you hosting Actual? Fly.io ### What browsers are you seeing the problem on? Chrome ### Operating System Linux
GiteaMirror added the user interfacebughelp wanted labels 2026-04-10 17:01:27 -05:00
GiteaMirror commented 2026-04-10 17:01:29 -05:00
Author
Owner
Copy Link

@Jackenmen commented on GitHub (Apr 2, 2023):

This is reproducible on the current edge image.

<!-- gh-comment-id:1493218704 --> @Jackenmen commented on GitHub (Apr 2, 2023): This is reproducible on the current edge image.
GiteaMirror commented 2026-04-10 17:01:30 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Apr 6, 2023):

👋 Thanks for the bug report. I was able to reproduce it and dug into it a bit. This smells like a case sensitivity bug somewhere.

When we query for transactions to display in the table we use a query like this.. WHERE LOWER(notes) LIKE %ē%. If you have two transactions with Ē and ē - only the lowercased transaction will be returned.

So it smells like a bug in better-sqlite3? Or perhaps misconfiguration on our end?

<!-- gh-comment-id:1499523196 --> @MatissJanis commented on GitHub (Apr 6, 2023): 👋 Thanks for the bug report. I was able to reproduce it and dug into it a bit. This smells like a case sensitivity bug somewhere. When we query for transactions to display in the table we use a query like this.. `WHERE LOWER(notes) LIKE %ē%`. If you have two transactions with `Ē` and `ē` - only the lowercased transaction will be returned. So it smells like a bug in `better-sqlite3`? Or perhaps misconfiguration on our end?
GiteaMirror commented 2026-04-10 17:01:31 -05:00
Author
Owner
Copy Link

@Jackenmen commented on GitHub (Apr 6, 2023):

When I was looking into it, I was unable to reproduce the problem with an analogous query in SQLite Browser on Actual's db file so it would make sense for it to be a better-sqlite3 bug or a misconfiguration.

<!-- gh-comment-id:1499532227 --> @Jackenmen commented on GitHub (Apr 6, 2023): When I was looking into it, I was unable to reproduce the problem with an analogous query in SQLite Browser on Actual's db file so it would make sense for it to be a better-sqlite3 bug or a misconfiguration.
GiteaMirror commented 2026-04-10 17:01:34 -05:00
Author
Owner
Copy Link

@Jackenmen commented on GitHub (Apr 6, 2023):

My testing confirms that this is an issue with better-sqlite3's behavior:
image

It looks like better-sqlite3 ships with a SQLite3 build without ICU support:
https://github.com/WiseLibs/better-sqlite3/issues/465

<!-- gh-comment-id:1499564645 --> @Jackenmen commented on GitHub (Apr 6, 2023): My testing confirms that this is an issue with better-sqlite3's behavior: ![image](https://user-images.githubusercontent.com/6032823/230484768-607226b7-d061-4d53-8a87-a6e1624cfc68.png) It looks like better-sqlite3 ships with a SQLite3 build without ICU support: https://github.com/WiseLibs/better-sqlite3/issues/465
GiteaMirror commented 2026-04-10 17:01:37 -05:00
Author
Owner
Copy Link

@MatissJanis commented on GitHub (Apr 6, 2023):

Good investigation @Jackenmen ! Would you want to pursue this further by opening a ticket with better-sqlite3? Or by continuing conversations in the linked ticket.

<!-- gh-comment-id:1499619290 --> @MatissJanis commented on GitHub (Apr 6, 2023): Good investigation @Jackenmen ! Would you want to pursue this further by opening a ticket with `better-sqlite3`? Or by continuing conversations in the linked ticket.
GiteaMirror commented 2026-04-10 17:01:37 -05:00
Author
Owner
Copy Link

@Jackenmen commented on GitHub (Apr 6, 2023):

I would prefer someone else to pursue it. I'm not sure if there's any chance for this to be improved in better-sqlite3 any time soon, though, considering it's a 2.5-year-old issue.

<!-- gh-comment-id:1499651674 --> @Jackenmen commented on GitHub (Apr 6, 2023): I would prefer someone else to pursue it. I'm not sure if there's any chance for this to be improved in `better-sqlite3` any time soon, though, considering it's a 2.5-year-old issue.
GiteaMirror commented 2026-04-10 17:01:38 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Apr 6, 2023):

I imagine ICU support would be very large (I believe Unicode data takes up most of the ~5MB size of SwiftWasm binaries) so perhaps the better option would be to do the case folding in JS?

<!-- gh-comment-id:1499721351 --> @j-f1 commented on GitHub (Apr 6, 2023): I imagine ICU support would be very large (I believe Unicode data takes up most of the ~5MB size of SwiftWasm binaries) so perhaps the better option would be to do the case folding in JS?
GiteaMirror commented 2026-04-10 17:01:38 -05:00
Author
Owner
Copy Link

@Jackenmen commented on GitHub (Apr 7, 2023):

After further investigation, I figured that we actually care more about sql.js not supporting ICU rather than better-sqlite3 since the former is actually being used in the web client while the latter no longer matters much now that there's no Electron client. The issue for that can be found here: https://github.com/sql-js/sql.js/issues/458

<!-- gh-comment-id:1499912566 --> @Jackenmen commented on GitHub (Apr 7, 2023): After further investigation, I figured that we actually care more about `sql.js` not supporting ICU rather than `better-sqlite3` since the former is actually being used in the web client while the latter no longer matters much now that there's no Electron client. The issue for that can be found here: https://github.com/sql-js/sql.js/issues/458
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
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug help wanted 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#7268
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?