mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-15 14:43:36 -05:00
[GH-ISSUE #7931] [Feature]: customizable transaction table columns for existing fields #117614
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#117614
Reference in New Issue
Block a user
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?
Originally created by @aaryan-rampal on GitHub (May 23, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/7931
Scope check: customizable transaction table columns for existing fields
I've read through some of the related history:
I'm opening this separately because the prior issues cover pieces of this, but this is not a custom-fields proposal. I want to be explicit up front: I'm NOT proposing user-defined custom fields here. I understand that is a larger product/data-model question, and that is not my goal.
What I'm interested in is whether maintainers would be open to a smaller PR direction: letting users customize the transaction table layout for fields Actual already stores or computes.
Initial scope could be:
Some examples of optional columns Actual could expose already with minimal work:
The main motivating case for me is Tags. I'm not trying to change the storage model yet. For this scope, tags can continue to be extracted from Notes. If maintainers think tags eventually need a deeper storage/model change, I'd be happy to help work on that too, but I want to keep that out of scope for this initial table-customization direction.
Furthermore, that list is not set in stone. I'm not saying all of these should be added, or that any specific one must be in the first PR. I'm listing them to show the kind of columns Actual could support right off the bat.
This also seems like it could address a few existing concerns together. Instead of debating whether there is room for a new column by default, the table can stay compact by default and users can choose which metadata is worth surfacing for their workflow.
Longer term, this could make the transaction table more modular as Actual adds new features. Even if a new feature starts small, it would not always need to fight for permanent default table space. It could expose an optional column, and users who care about that workflow could turn it on.
Would maintainers be open to a PR in this direction if it starts narrowly, globally, and only exposes existing fields?
@MatissJanis commented on GitHub (May 23, 2026):
We're looking to do a transaction table rewrite this year. Possibly to use react-table, datatable or react aria table.
Moving to a proper table lib will unlock most of these features.
If you want to help with this refactor - we're open to that.
@github-actions[bot] commented on GitHub (May 23, 2026):
✨ Thanks for sharing your idea! ✨
This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution).
The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+
Don't forget to upvote the top comment with 👍!
@MatissJanis commented on GitHub (May 23, 2026):
Ps - we use Discord for similar discussions. That will be a better suited place to talk about this.
@aaryan-rampal commented on GitHub (May 23, 2026):
Sounds great, yeah would be down to help out. I'll check out the discord thanks for the shout!