github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-16 23:26:48 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #7580] [Bug]: v26.4.0 Undo Action (Cmd + Z) causes file importer to treat transactions as previously deleted. #80550

New Issue
Closed
opened 2026-05-19 04:20:45 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-05-19 04:20:45 -05:00
Owner
Copy Link

Originally created by @toduyemi on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/7580

What happened?

Issue
Undo is not the equivalent of deleting transaction records. It is a return to previous state, for all intents and purposes those transactions were never in Actual. Deleted transactions are intentional removals in which a new state of the ledger is created. This has never been an issue before, this flow is something I rely on heavily. I suspect it is due to the recent update.

Expected behaviour
After Undo, file imports should not be treated as deleted transactions. Transactions not yet in Actual should be already checked

Actual behaviour
When using Undo Shortcut to return Actual to a previous state (in this case Undo File Import), upon importing the file, Actual's importer treats transactions that came before the undo as a "deleted transaction". It is greyed. This requires the user to go through the import ledger and manually sort out which greyed out transactions belong in this import.

How can we reproduce the issue?

  1. Go to an Account
  2. Import QFX file.
  3. Trigger Undo
  4. Click import again
  5. Observe transactions that should be viewed as fresh imports are greyed out.

Where are you hosting Actual?

Pikapods

What browsers are you seeing the problem on?

Safari

Operating System

Mac OSX

Originally created by @toduyemi on GitHub (Apr 21, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/7580 ### What happened? **Issue** `Undo` is not the equivalent of deleting transaction records. It is a return to previous state, for all intents and purposes those transactions were never in Actual. Deleted transactions are intentional removals in which a new state of the ledger is created. This has never been an issue before, this flow is something I rely on heavily. I suspect it is due to the recent update. **Expected behaviour** After `Undo`, file imports should not be treated as deleted transactions. Transactions not yet in Actual should be already checked **Actual behaviour** When using Undo Shortcut to return Actual to a previous state (in this case Undo File Import), upon importing the file, Actual's importer treats transactions that came before the undo as a "deleted transaction". It is greyed. This requires the user to go through the import ledger and manually sort out which greyed out transactions belong in this import. ### How can we reproduce the issue? 1. Go to an Account 2. Import QFX file. 3. Trigger `Undo` 4. Click import again 5. Observe transactions that should be viewed as fresh imports are greyed out. ### Where are you hosting Actual? Pikapods ### What browsers are you seeing the problem on? Safari ### Operating System Mac OSX
GiteaMirror added the bugtransaction import labels 2026-05-19 04:20:45 -05:00
GiteaMirror commented 2026-05-19 04:20:47 -05:00
Author
Owner
Copy Link

@matt-fidd commented on GitHub (Apr 22, 2026):

Probable cause: https://github.com/actualbudget/actual/pull/6926

<!-- gh-comment-id:4296259656 --> @matt-fidd commented on GitHub (Apr 22, 2026): Probable cause: https://github.com/actualbudget/actual/pull/6926
GiteaMirror commented 2026-05-19 04:20:48 -05:00
Author
Owner
Copy Link

@matt-fidd commented on GitHub (Apr 22, 2026):

I wasn't involved in the change, but it looks like this was a deliberate change. You can tick the "reimport deleted transactions" checkbox in the import modal to allow it to import previously imported transactions. It should save the preference between imports so you'll only need to tick it once

Getting into the weeds a bit more, "undo" after importing does (and always has) actually set the transactions to deleted by use of a tombstone flag. The CRDT sync layer we use does not support outright deletion or reversion, it's just that the UI has changed how they are treated in imports by default.

<!-- gh-comment-id:4296278172 --> @matt-fidd commented on GitHub (Apr 22, 2026): I wasn't involved in the change, but it looks like this was a deliberate change. You can tick the "reimport deleted transactions" checkbox in the import modal to allow it to import previously imported transactions. It should save the preference between imports so you'll only need to tick it once Getting into the weeds a bit more, "undo" after importing does (and always has) actually set the transactions to deleted by use of a tombstone flag. The CRDT sync layer we use does not support outright deletion or reversion, it's just that the UI has changed how they are treated in imports by default.
GiteaMirror commented 2026-05-19 04:20:48 -05:00
Author
Owner
Copy Link

@toduyemi commented on GitHub (Apr 22, 2026):

You can tick the "reimport deleted transactions" checkbox in the import modal to allow it to import previously imported transactions. It should save the preference between imports so you'll only need to tick it once

@matt-fidd apologies I should have mentioned in my ticket. The reimport deleted transactions checkbox, creates another issue birthed again from the lack of differentiating between undone imports and deleted imports. So transactions I intentionally deleted are reimported along with the import. Every time. No matter what I still have to go through the ledger and manually sort for what used to be a simple import task flow. I'm going to have to do that for the same transactions every time.

The solution proffered in that PR addresses another problem at cost of introducing this issue as a side effect. To my experience, the import engine worked perfectly fine and I has zero issues with its handling of deleted transactions. The backend may have seen the transaction "undos" as deleted, but to users and previously user facing Actual, there is a distinction. I'd appreciate if this issue was reopened as this behaviour (removal of that distinction) seems accidental as "undo" isn't mentioned in that PR.

<!-- gh-comment-id:4298575677 --> @toduyemi commented on GitHub (Apr 22, 2026): > You can tick the "reimport deleted transactions" checkbox in the import modal to allow it to import previously imported transactions. It should save the preference between imports so you'll only need to tick it once @matt-fidd apologies I should have mentioned in my ticket. The reimport deleted transactions checkbox, creates another issue birthed again from the lack of differentiating between undone imports and deleted imports. So transactions I intentionally deleted are reimported along with the import. Every time. No matter what I still have to go through the ledger and manually sort for what used to be a simple import task flow. I'm going to have to do that for the same transactions every time. The solution proffered in that PR addresses another problem at cost of introducing this issue as a side effect. To my experience, the import engine worked perfectly fine and I has zero issues with its handling of deleted transactions. The backend may have seen the transaction "undos" as deleted, but to users and previously user facing Actual, there is a distinction. I'd appreciate if this issue was reopened as this behaviour (removal of that distinction) seems accidental as "undo" isn't mentioned in that PR.
GiteaMirror commented 2026-05-19 04:20:49 -05:00
Author
Owner
Copy Link

@alecbakholdin commented on GitHub (Apr 23, 2026):

I'm able to reproduce this only with QFX, not CSV files. The content below saved as file.qfx successfully reproduces the issue. Also confirmed that this behavior is new to v26.4.0

<OFX>
  <SIGNONMSGSRSV1>
    <SONRS>
      <STATUS><CODE>0</CODE><SEVERITY>INFO</SEVERITY></STATUS>
      <DTSERVER>20240420120000</DTSERVER>
      <LANGUAGE>ENG</LANGUAGE>
      <INTU.BID>1234</INTU.BID>
    </SONRS>
  </SIGNONMSGSRSV1>
  <BANKMSGSRSV1>
    <STMTTRNRS>
      <STMTRS>
        <CURDEF>USD</CURDEF>
        <BANKTRANLIST>
          <DTSTART>20240401120000</DTSTART>
          <DTEND>20240420120000</DTEND>
          
          <!-- Transaction 1: Debit Purchase -->
          <STMTTRN>
            <TRNTYPE>DEBIT</TRNTYPE>
            <DTPOSTED>20240415120000</DTPOSTED>
            <TRNAMT>-45.00</TRNAMT>
            <FITID>20240415001</FITID>
            <NAME>SAMPLE COFFEE SHOP</NAME>
          </STMTTRN>

          <!-- Transaction 2: Payroll Deposit -->
          <STMTTRN>
            <TRNTYPE>CREDIT</TRNTYPE>
            <DTPOSTED>20240416090000</DTPOSTED>
            <TRNAMT>2500.00</TRNAMT>
            <FITID>20240416002</FITID>
            <NAME>EMPLOYER PAYROLL PPD</NAME>
          </STMTTRN>

          <!-- Transaction 3: Check Payment -->
          <STMTTRN>
            <TRNTYPE>CHECK</TRNTYPE>
            <DTPOSTED>20240418120000</DTPOSTED>
            <TRNAMT>-850.00</TRNAMT>
            <FITID>20240418003</FITID>
            <CHECKNUM>101</CHECKNUM>
            <NAME>APARTMENT RENT</NAME>
          </STMTTRN>

          <!-- Transaction 4: Grocery Purchase -->
          <STMTTRN>
            <TRNTYPE>DEBIT</TRNTYPE>
            <DTPOSTED>20240420183000</DTPOSTED>
            <TRNAMT>-112.45</TRNAMT>
            <FITID>20240420004</FITID>
            <NAME>WHOLE FOODS MARKET</NAME>
          </STMTTRN>

        </BANKTRANLIST>
      </STMTRS>
    </STMTTRNRS>
  </BANKMSGSRSV1>
</OFX>
<!-- gh-comment-id:4309289365 --> @alecbakholdin commented on GitHub (Apr 23, 2026): I'm able to reproduce this only with QFX, not CSV files. The content below saved as file.qfx successfully reproduces the issue. Also confirmed that this behavior is new to v26.4.0 ``` <OFX> <SIGNONMSGSRSV1> <SONRS> <STATUS><CODE>0</CODE><SEVERITY>INFO</SEVERITY></STATUS> <DTSERVER>20240420120000</DTSERVER> <LANGUAGE>ENG</LANGUAGE> <INTU.BID>1234</INTU.BID> </SONRS> </SIGNONMSGSRSV1> <BANKMSGSRSV1> <STMTTRNRS> <STMTRS> <CURDEF>USD</CURDEF> <BANKTRANLIST> <DTSTART>20240401120000</DTSTART> <DTEND>20240420120000</DTEND> <!-- Transaction 1: Debit Purchase --> <STMTTRN> <TRNTYPE>DEBIT</TRNTYPE> <DTPOSTED>20240415120000</DTPOSTED> <TRNAMT>-45.00</TRNAMT> <FITID>20240415001</FITID> <NAME>SAMPLE COFFEE SHOP</NAME> </STMTTRN> <!-- Transaction 2: Payroll Deposit --> <STMTTRN> <TRNTYPE>CREDIT</TRNTYPE> <DTPOSTED>20240416090000</DTPOSTED> <TRNAMT>2500.00</TRNAMT> <FITID>20240416002</FITID> <NAME>EMPLOYER PAYROLL PPD</NAME> </STMTTRN> <!-- Transaction 3: Check Payment --> <STMTTRN> <TRNTYPE>CHECK</TRNTYPE> <DTPOSTED>20240418120000</DTPOSTED> <TRNAMT>-850.00</TRNAMT> <FITID>20240418003</FITID> <CHECKNUM>101</CHECKNUM> <NAME>APARTMENT RENT</NAME> </STMTTRN> <!-- Transaction 4: Grocery Purchase --> <STMTTRN> <TRNTYPE>DEBIT</TRNTYPE> <DTPOSTED>20240420183000</DTPOSTED> <TRNAMT>-112.45</TRNAMT> <FITID>20240420004</FITID> <NAME>WHOLE FOODS MARKET</NAME> </STMTTRN> </BANKTRANLIST> </STMTRS> </STMTTRNRS> </BANKMSGSRSV1> </OFX> ```
GiteaMirror commented 2026-05-19 04:20:49 -05:00
Author
Owner
Copy Link

@alecbakholdin commented on GitHub (Apr 24, 2026):

Workaround

@toduyemi if you check the "reimport deleted transactions" box, this should behave exactly as it did in v26.3.0.

Explanation

In both v26.3.0 and v26.4.0, undo performs a soft delete, so that part has not changed. The part that changed is the new "reimport deleted transactions" feature, which changed the default behavior. The new default is false, but the old functionality behaved as though this checkbox was true. This kind of breaks regression so @matt-fidd I'll leave it up to you but would probably recommend changing the default value to true to restore functionality from 26.3.0. I'll put up a PR with this change and also make the property a synced pref to make it persist between imports.

The deleted transactions are matched by their FITID (in Actual, this would be "imported_id" aka bank sync ID). If you remove the FITID from the ofx files, you'll see it behaves the same as it did in 26.3.0.

Why Soft Delete

I don't think I'm fully qualified to describe why the Actual sync model uses soft delete for undo, but the short of it is that since we are using an offline-first distributed sync model, there are some edge cases that arise from hard deletes at any stage, including undos. I would say, while I understand your frustration regarding the results of this soft delete, since there is a pretty straightforward workaround with the reimport deleted transactions checkbox, you should be fine for now until I revert the default behavior to what it was.

<!-- gh-comment-id:4314200303 --> @alecbakholdin commented on GitHub (Apr 24, 2026): ### Workaround @toduyemi if you check the "reimport deleted transactions" box, this should behave exactly as it did in v26.3.0. ### Explanation In both v26.3.0 and v26.4.0, undo performs a soft delete, so that part has not changed. The part that changed is the new "reimport deleted transactions" feature, which changed the default behavior. The new default is false, but the old functionality behaved as though this checkbox was true. This kind of breaks regression so @matt-fidd I'll leave it up to you but would probably recommend changing the default value to true to restore functionality from 26.3.0. I'll put up a PR with this change and also make the property a synced pref to make it persist between imports. The deleted transactions are matched by their FITID (in Actual, this would be "imported_id" aka bank sync ID). If you remove the FITID from the ofx files, you'll see it behaves the same as it did in 26.3.0. ### Why Soft Delete I don't think I'm fully qualified to describe why the Actual sync model uses soft delete for undo, but the short of it is that since we are using an offline-first distributed sync model, there are some edge cases that arise from hard deletes at any stage, including undos. I would say, while I understand your frustration regarding the results of this soft delete, since there is a pretty straightforward workaround with the reimport deleted transactions checkbox, you should be fine for now until I revert the default behavior to what it was.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug transaction import
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#80550
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?