[Bug]: Filtered balance on Split's notes not calculating properly #1863

Open
opened 2026-02-28 19:56:35 -06:00 by GiteaMirror · 2 comments
Owner

Originally created by @Rescue9 on GitHub (Feb 14, 2025).

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). ### 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 transactionsbughelp wanted labels 2026-02-28 19:56:35 -06:00
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#1863