Skip to content
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

[Bug]: API import transactions overrides some fields, not others, hard to make sense #1827

Open
1 task done
cpainchaud opened this issue Oct 26, 2023 · 1 comment
Open
1 task done
Labels
bug Something isn't working

Comments

@cpainchaud
Copy link

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

when using API to import transactions, if they already exist (same imported_id) then an odd behavior happens:

  • if the 'updated' transaction has changed amount, it will not take it in account and keep the old one
  • if the 'updated' transaction has changed the 'cleared' status, it will use that new status. ommiting the status will force it to True

I do believe it should be the contrary:

  • there are good reason to update an amount and it should not be ignored by the import call
  • 'Cleared' should not be touched, it's what people use to check operations was reviewed.

selfhosted fresh v23.10.0 servers and client. API version 6.2.1

What error did you receive?

no error in particular

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome, Other

Operating System

Windows 10

@cpainchaud cpainchaud added the bug Something isn't working label Oct 26, 2023
@tavlima
Copy link

tavlima commented Dec 17, 2023

Here is another perspective: depending on what your import source is, it may actually be the source of truth, including whether the transaction is cleared or not.

But I agree with you that the current behavior is non-intuitive. Here is what I think would make some sense, from what I could see:

  1. an additional boolean argument to the import API that overwrites the existing data with whatever new data is provided (if true and if there is a matching imported_id, of course)
  2. now that a "reconciled" flag was introduced, ensure that no import call touches any transaction field (unless using the flag I suggested above)

My goal with (1) is being able to rewrite my importers to fine-tune some inferred notes/payees/categories and not have to manually delete the previously importer transactions for that.

(2) is about an issue I just found, where I had to manually fix some transaction dates for imported transactions, only to have them overwritten again by the next import, even though they were already reconciled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants