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

[GH-ISSUE #4381] [Bug]: Filtered balance on Split's notes not calculating properly #99277

New Issue
Open
opened 2026-05-29 14:34:50 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-29 14:34:50 -05:00
Owner
Copy Link

Originally created by @Rescue9 on GitHub (Feb 14, 2025).
Original GitHub issue: https://github.com/actualbudget/actual/issues/4381

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

When trying to filter transactions by Note, the "Filtered Balance" doesn't include the split if each line doesn't also have the note.

I would expect that the split be included if each split note is empty. If each split has a different note, then those splits should be filtered accordingly. For example, in the image, if the note on the External Purchases split said "Family" I would not expect it to calculate in the "contains kro" filter. However, those splits that are empty should calculate. Otherwise, every split needs to have all fields filed out to calculate properly.

Image

How can we reproduce the issue?

How can we reproduce the issue?
Create a split transaction, notate the main split, but not the individual sub-splits, filter by note. Filtered Balance will be different than expected, and not show non-notated sub-splits.

Where are you hosting Actual?

Locally via Yarn

What browsers are you seeing the problem on?

Chrome, Firefox

Operating System

Windows 11

Originally created by @Rescue9 on GitHub (Feb 14, 2025). Original GitHub issue: https://github.com/actualbudget/actual/issues/4381 ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? When trying to filter transactions by Note, the "Filtered Balance" doesn't include the split if each line doesn't also have the note. I would expect that the split be included if each split note is empty. If each split has a different note, then those splits should be filtered accordingly. For example, in the image, if the note on the External Purchases split said "Family" I would not expect it to calculate in the "contains kro" filter. However, those splits that are empty should calculate. Otherwise, every split needs to have all fields filed out to calculate properly. ![Image](https://github.com/user-attachments/assets/e1d917ad-0658-4ec3-bf8a-6d421f9f1347) ### How can we reproduce the issue? How can we reproduce the issue? Create a split transaction, notate the main split, but not the individual sub-splits, filter by note. Filtered Balance will be different than expected, and not show non-notated sub-splits. ### Where are you hosting Actual? Locally via Yarn ### What browsers are you seeing the problem on? Chrome, Firefox ### Operating System Windows 11
GiteaMirror added the help wantedbugtransactions labels 2026-05-29 14:34:52 -05:00
GiteaMirror commented 2026-05-29 14:34:54 -05:00
Author
Owner
Copy Link

@alecbakholdin commented on GitHub (Feb 26, 2025):

I looked into this and I'm able to reproduce it as well, not just in the account filter but also in reports if you make a custom report and add a filter that matches both child and parent, you will only see the parent transaction. The issue seems to be happening here 5214549ed3/packages/loot-core/src/server/aql/schema/executors.ts (L98)

if (isAggregateQuery(queryState)) {
    const s = { ...sql };

    // Modify the where to only include non-parents
    s.where = `${s.where} AND ${s.from}.is_parent = 0`;

    // We also want to exclude deleted transactions. Normally we
    // handle this manually down below, but now that we are doing a
    // normal query we want to rely on the view. Unfortunately, SQL
    // has already been generated so we can't easily change the view
    // name here; instead, we change it and map it back to the name
    // used elsewhere in the query. Ideally we'd improve this
    if (!withDead) {
      s.from = 'v_transactions_internal_alive v_transactions_internal';
}

(Note the ${s.from}.is_parent = 0) For aggregate queries we simply don't consider split parent transactions at all. I don't immediately see a good solution to this and I'm new to the codebase so probably shouldn't be modifying something as integral as this right now.

<!-- gh-comment-id:2686244506 --> @alecbakholdin commented on GitHub (Feb 26, 2025): I looked into this and I'm able to reproduce it as well, not just in the account filter but also in reports if you make a custom report and add a filter that matches both child and parent, you will only see the parent transaction. The issue seems to be happening here https://github.com/actualbudget/actual/blob/5214549ed3f6d8f8370ef262e27e2609d88ade53/packages/loot-core/src/server/aql/schema/executors.ts#L98 ``` if (isAggregateQuery(queryState)) { const s = { ...sql }; // Modify the where to only include non-parents s.where = `${s.where} AND ${s.from}.is_parent = 0`; // We also want to exclude deleted transactions. Normally we // handle this manually down below, but now that we are doing a // normal query we want to rely on the view. Unfortunately, SQL // has already been generated so we can't easily change the view // name here; instead, we change it and map it back to the name // used elsewhere in the query. Ideally we'd improve this if (!withDead) { s.from = 'v_transactions_internal_alive v_transactions_internal'; } ``` (Note the `${s.from}.is_parent = 0`) For aggregate queries we simply don't consider split parent transactions at all. I don't immediately see a good solution to this and I'm new to the codebase so probably shouldn't be modifying something as integral as this right now.
GiteaMirror commented 2026-05-29 14:34:55 -05:00
Author
Owner
Copy Link

@Mansarde commented on GitHub (Jun 4, 2025):

But what if both the parent and one of its child-transactions had "Kroger Card" in the notes?

A) Should only the parent amount be counted?
B) Or only the child amount?
C) Or both?

If A), then why does the parent amount take precedence over the child amount? After all, if a child doesn't match the note, why should its amount be be indirectly counted (seeing as it's a part of the parent amount)?

If B), then we have how it works right now. Only the amounts of child entries that match will be counted. If only a parent matches, but no child, then the matched amount might be 0, but if you select that parent, the selected amount will count the parent.

If C), then you would be counting the child amount two times, because it's already included in the parent amount.

Out of these three options, B) seems to produce the least issues IMO.
In your example, simply select all and see the difference between the matched amount and the selected amount.
The latter is probably what you were seeking, but the former is also useful information in case you tagged specific split-transactions.

<!-- gh-comment-id:2941419614 --> @Mansarde commented on GitHub (Jun 4, 2025): But what if both the parent and one of its child-transactions had "Kroger Card" in the notes? A) Should only the parent amount be counted? B) Or only the child amount? C) Or both? If A), then why does the parent amount take precedence over the child amount? After all, if a child doesn't match the note, why should its amount be be indirectly counted (seeing as it's a part of the parent amount)? If B), then we have how it works right now. Only the amounts of child entries that match will be counted. If only a parent matches, but no child, then the *matched* amount might be 0, but if you select that parent, the *selected* amount will count the parent. If C), then you would be counting the child amount two times, because it's already included in the parent amount. Out of these three options, B) seems to produce the least issues IMO. In your example, simply select all and see the difference between the matched amount and the selected amount. The latter is probably what you were seeking, but the former is also useful information in case you tagged specific split-transactions.
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 help wanted transactions
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#99277
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?