mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-16 07:04:23 -05:00
[Bug]: Rule from transaction doesn't populate category #334
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#334
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 @rich-howell on GitHub (Apr 7, 2023).
Verified issue does not already exist?
What happened?
When selecting a transaction in the account register and selecting Create Rule from the dropdown the category the transaction was assigned in the register is not populated in the rule modal.
Here is a screenshot of the transaction
Here is a screenshot of the rule window presented when creating a rule from the above trasnaction.
What error did you receive?
None.
Where are you hosting Actual?
Fly.io
What browsers are you seeing the problem on?
Microsoft Edge
Operating System
Windows 11
@MatissJanis commented on GitHub (Apr 11, 2023):
👋 Starting a discussion here: how should the rule creation in transaction table behave?
From one perspective: Rich's suggestion of adding "category" to the "apply rules" section makes sense as it's one of the most common operations.
BUT: why is "category" exclusive here? Should "notes" also behave the same way? What about"cleared" status? And why are "payee"/"imported payee" fields being set in the conditions section instead of the "apply rules" section below?
To me it feels like we need to have a conversation about how to make this experience consistent.
FYI: I'm not for or against the proposed change. Personally I don't know what would be the bets path forward here, so looking to hear what others think.
@rich-howell commented on GitHub (Apr 11, 2023):
If I select a transaction and then click Create Rule that is what I expect to happen, that initially isn't what happened. The PR fixed it, I was just being overly critical when testing I am not sure what should happen when more than 1 transaction is selected though, maybe the Create rule option should not appear when that workflow happens.
I don't think it is but category seems like the most common thing you are going to want to have pre-populated when selecting a transaction and then wanting to create a rule, otherwise it seems like the functionality is broken.
Maybe what would be a better workflow for the Create Rule would be similar to how Outlook handles it, you get a box that shows you the available data and you can select which you want to apply to that Rule.
Seems complicated....
@shall0pass commented on GitHub (Apr 11, 2023):
I agree that setting the category is the most common use. These rules are run during file imports, bank sync, and manual entry and in most cases the payee or imported payee is known but the category is unknown. There was discussion about possibly a 'right click' or '...' menu on the individual lines entry lines. To me, this seems like something that is more suited to a single entry and would fit better there rather than the multiple entry selection menu, or like Rich suggested, simply disabling the rule creation with multiple selections.
Adding the 'notes' and 'cleared' status, I think, is a good idea. It takes more effort to add them if they're not populated than it is to remove them both (2 clicks) if they're not needed.
@MatissJanis commented on GitHub (Apr 11, 2023):
Generally I agree with what you're both saying. But one question we haven't answered yet: why are "payee"/"imported payee" fields being set in the conditions section instead of the "apply rules" section below?
What's the logic for "X field goes in the conditions part and Y field goes in the apply rules section"?
@shall0pass commented on GitHub (Apr 11, 2023):
I would group things into the "Things you probably know" (conditions) and "Things you probably don't know" (actions) when you import transactions. Something to that end will capture most use cases.
Personally, I would omit Date because it's too specific and would limit the usefulness of the rule. I would also eliminate cleared status because that's usually taken care of using another rule during the import process. I'm unfamiliar with how Notes are imported through files or bank sync, but if it's populated there's an opportunity to parse the Notes field to set a rule so I would lean towards putting it in conditions.
Things you probably know:
Date
Payee
Cleared status
Amount (inflow/outflow)
**Notes - this could go either way I think.
Things you probably don't know:
Category
**Notes
@MatissJanis commented on GitHub (Apr 13, 2023):
That makes sense.
So the most sensible solution would be to pre-populate
category. Which is what Rich suggested. I'm ok with that.