Replies: 7 comments
-
Hey @winklevos This looks to be by design, if you take a look at the documentation https://actualbudget.com/docs/other/rules/ it states the following;
Actual will create a rule based on how you use it. Hope this helps, if you need anything more please do reach out or @ me in discord and I will re-open this issue. |
Beta Was this translation helpful? Give feedback.
-
@rich-howell this bug is saying it isn't creating as per this documentation. When categorising transactions rules are not created automatically. I have a working fix in progress that adds the behaviour I expect |
Beta Was this translation helpful? Give feedback.
-
I am happy to re-open this for you, however this isn't a bug. The rules engine will decide when a rule needs to be created based on the factors used within the transaction. If you just create one transaction for say Grocery and select the merchant and value a rule won't be created because you would end up with rules for every single thing. I am not sure if you will get your PR merged into main if it create a rule for every single transaction added, but I will leave this open for James to review when the time comes. |
Beta Was this translation helpful? Give feedback.
-
This is the exact user experience I expect and is standard in budgeting apps. Ultimately a user should not have to manually categorise as much as possible. If creating a rule for each payee is going to be a problem we might need to change some things. I see the functionality like so
I've imported 10,000 transactions into actual, the user experience currently will result in me not being able to use it. I hope this feature can be considered beneficial for actual |
Beta Was this translation helpful? Give feedback.
-
For note, the current logic is in https://github.com/winklevos/actual/blob/categorise-rules/packages/loot-core/src/server/accounts/transaction-rules.js#L614 Goes as follows When the category is changed actual will look back 6 months, and forward 180 days. And get all related transactions for that payee. It will only continue if you modified the latest transactions. It will then count the number of occurrences of that category for the payee. It selects the category with the majority (max). And only updates if it has > 3 occurrences. Think
This to me is a bit overbuilt, see my previous three points for UX |
Beta Was this translation helpful? Give feedback.
-
As this isn't a bug I am going to move it over to ideas for further discussion. |
Beta Was this translation helpful? Give feedback.
-
I am going to go ahead and close this, Actual is working as designed, when a new transaction is added that has a new payee and category a rule will not be created until that combination of payee & category has been utilised n number of times. If you would like to change this, I suggest creating an RFC with an associated PR so the project team can evaluate. Cheers |
Beta Was this translation helpful? Give feedback.
-
When creating a new transaction and a new payee, adding a category does not auto-create a related rule
The same occurs when updating an existing transaction from uncategorised
Browser: Firefox and Chrome
Version: https://hub.docker.com/r/kippenhof/actual-server latest
Confirmed the same behaviour locally building from master
Beta Was this translation helpful? Give feedback.
All reactions