-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Add transfers to merge #5001
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Add transfers to merge #5001
Conversation
✅ Deploy Preview for actualbudget ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Bundle Stats — desktop-clientHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset No files were changed View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger No assets were bigger Smaller No assets were smaller Unchanged
|
Bundle Stats — loot-coreHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset
View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger
Smaller No assets were smaller Unchanged No assets were unchanged |
what would cause the second situation? Maybe you could make a demo file that shows the different merge situations so we could test more easily/consistently |
The second situation happens when the kept transaction has a payee or is a transfer already and the dropped transaction is a transfer. I'll create a test file in a bit |
My first thought is that in case 2, you should remove the payee/link, but leave the linked transaction in place (as uncategorized). This will flag the user that the transaction needs to be dealt with and avoids "silently" deleting a transaction. My best guess as to how you get there is that an import/rule results in two sets of transactions for a single transfer (i.e. 4 total transactions). In that case, it would make sense to delete the linked one, but you may get odd behavior on which one gets deleted (i.e. if I merge the auto-created tx to a bank tx on one side, it may delete the bank tx on the other side instead of the auto-created one). So yeah, I think it would make the most sense to leave the transaction and let the user merge or delete manually. Just my two cents :) |
The file below demonstrates situation 2. When you merge the two transactions in "account1" (shown in image below) Notice that the dropped transfer gets deleted from account2. What @cesjn is proposing is to keep that transaction in account2 like so: |
Im thinking not deleting the other side would be better. For example if the other side is reconciled, this will still delete it |
Closes #5000
Initially discussed in #4899
Adds support for merging transferred transaction.
Please, someone confirm if this sounds okay. This is all reversible with ctrl + z but I worry especially about the second point. To me it sounds reasonable but the alternative is we make the other transaction payee-less instead of deleting it. That seems odd as well but need advice.