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 #7644] [Bug]: Custom report conditions ignored when switching to data table view #117519

New Issue
Open
opened 2026-06-11 12:44:52 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-06-11 12:44:52 -05:00
Owner
Copy Link

Originally created by @christso on GitHub (Apr 28, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/7644

What happened?

When a custom report has a conditions/filter set (e.g. Notes contains #groceries), the filter is applied correctly in graph views (AreaGraph, etc.) but is silently ignored when switching to the data table view. The last-used view mode also persists, so subsequent opens of the same report from a dashboard card open in data table mode with no filter applied.

  • Expected: conditions apply in all view modes (graph and data table)
  • Actual: conditions apply only in graph view; data table shows all transactions regardless of saved conditions

Screenshots below show the difference (AreaGraph filtered vs data table unfiltered).

How can we reproduce the issue?

  1. Create a custom report — e.g. Name: "Groceries", Graph: AreaGraph, add filter Notes → contains → #groceries
  2. Save. Verify the AreaGraph chart shows only #groceries-tagged data ✓
  3. Click the data table icon (⊞) to switch to table view
  4. Observe: the table shows all transactions — the contains condition is not applied ✗
  5. Navigate away (e.g. go to Budget, then back to Reports)
  6. Click the same report card — it reopens in data table mode with no filter applied ✗

Additional finding: the hasTags operator is listed in @actual-app/api's disallowedOps for custom report conditions, causing those conditions to be silently discarded entirely. We worked around this by using contains instead — but contains still fails in the data table view. This suggests condition handling may be implemented per-renderer rather than at the data layer.

Where are you hosting Actual?

Docker (self-hosted)

What browsers are you seeing the problem on?

Chrome

Operating System

Linux

Screenshots to follow in comments.

Originally created by @christso on GitHub (Apr 28, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/7644 ## What happened? When a custom report has a **conditions/filter** set (e.g. Notes `contains` `#groceries`), the filter is applied correctly in graph views (AreaGraph, etc.) but is **silently ignored** when switching to the data table view. The last-used view mode also persists, so subsequent opens of the same report from a dashboard card open in data table mode with no filter applied. - Expected: conditions apply in all view modes (graph and data table) - Actual: conditions apply only in graph view; data table shows all transactions regardless of saved conditions Screenshots below show the difference (AreaGraph filtered vs data table unfiltered). ## How can we reproduce the issue? 1. Create a custom report — e.g. Name: "Groceries", Graph: AreaGraph, add filter **Notes → contains → `#groceries`** 2. Save. Verify the AreaGraph chart shows only `#groceries`-tagged data ✓ 3. Click the **data table icon** (⊞) to switch to table view 4. Observe: the table shows **all transactions** — the `contains` condition is not applied ✗ 5. Navigate away (e.g. go to Budget, then back to Reports) 6. Click the same report card — it reopens in data table mode with no filter applied ✗ **Additional finding:** the `hasTags` operator is listed in `@actual-app/api`'s `disallowedOps` for custom report conditions, causing those conditions to be silently discarded entirely. We worked around this by using `contains` instead — but `contains` still fails in the data table view. This suggests condition handling may be implemented per-renderer rather than at the data layer. ## Where are you hosting Actual? Docker (self-hosted) ## What browsers are you seeing the problem on? Chrome ## Operating System Linux --- _Screenshots to follow in comments._
GiteaMirror commented 2026-06-11 12:44:54 -05:00
Author
Owner
Copy Link

@alecbakholdin commented on GitHub (Apr 28, 2026):

I think this is even more general than described. A few of things of note:

  1. Any filter, e.g. Account is <acc>, Reconciled is true, Transfer is false will reproduce this.
  2. If multiple filters are defined, they will all disappear
  3. Area graph/data table is not relevant. Switching graph views of any kind can reproduce.

Some more general steps to reproduce:

  1. Save a custom report with a filter
  2. Go to edit that report
  3. Switch views (e.g. area graph => donut, data table => bar graph)
  4. "Update Report"
  5. Refresh the page

You will see all your filters defined in step disappear, also the report shows (modified) in the top right.

These steps are are like 95% consistent, sometimes they don't work...

<!-- gh-comment-id:4331569723 --> @alecbakholdin commented on GitHub (Apr 28, 2026): I think this is even more general than described. A few of things of note: 1. *Any* filter, e.g. `Account is <acc>`, `Reconciled is true`, `Transfer is false` will reproduce this. 2. If multiple filters are defined, they will all disappear 3. Area graph/data table is not relevant. Switching graph views of any kind can reproduce. Some more general steps to reproduce: 1. Save a custom report with a filter 2. Go to edit that report 3. Switch views (e.g. area graph => donut, data table => bar graph) 4. "Update Report" 5. Refresh the page You will see all your filters defined in step disappear, also the report shows (modified) in the top right. These steps are are like 95% consistent, sometimes they don't work...
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
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#117519
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?