github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-15 22:54:03 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #7796] [Bug]: Skipping end lines when importing CSV resets all fields #100616

New Issue
Open
opened 2026-05-29 20:55:53 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-29 20:55:53 -05:00
Owner
Copy Link

Originally created by @andrebk on GitHub (May 11, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/7796

What happened?

I was importing a CSV file of transactions for an account for the first time. I selected the correct delimiter, all the correct column fields, date format, amount options etc. and was looking through the transactions to verify things were correct when I saw that the bottom rows were gibberish.

I check the CSV file and see that the last few lines are summary lines which shouldn't be included. No worries, I see there is a "skip end lines" option so I just set that to the number of summary lines and... wait, now all my transactions are gibberish? What happened?

Turns out changing the number of skipped end lines resets all the options for CSV fields, date format, and amount options. This actually happens for all the options that changes the number of lines or how they're split (delimiter, skip start lines, skip end lines, and file has header row).

This actually makes a lot of sense for the other three, since they will change the first line that is used to determine the column names that you select for the CSV fields options, so then the options you selected from before are no longer valid and will have to be reset. But the skip end lines doesn't change this first line unless you select a number greater than the number of rows (in which case there are no lines left at all, so it should be obvious that this was a mistake).

Because the bottom lines are hidden from view if there are a lot of transactions it's easy to not notice you even need to ignore lines before you start selecting fields. And because so many fields are reset, it's really annoying to have to redo all of them, leading to an all around bad user experience.

Expected behaviour: Changing skip end lines just removes some transactions from the end of the list without changing any other transactions.

Actual behaviour: Changing skip end lines resets all CSV options selected, messing up all the remaining transactions and forcing you to redo your work.

Observed on version 26.5.2

How can we reproduce the issue?

  1. Go to an account
  2. Click the Import button
  3. Select any CSV file
  4. Change any option under CSV FIELDS, DATE FORMAT or AMOUNT OPTIONS, for example click the Flip amount checkbox to True
  5. Change the number in the Skip end lines number input
  6. Observe that the options you set before have now been reset, for example the Flip amount checkbox will now be false

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Firefox

Operating System

Linux

Originally created by @andrebk on GitHub (May 11, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/7796 ### What happened? I was importing a CSV file of transactions for an account for the first time. I selected the correct delimiter, all the correct column fields, date format, amount options etc. and was looking through the transactions to verify things were correct when I saw that the bottom rows were gibberish. I check the CSV file and see that the last few lines are summary lines which shouldn't be included. No worries, I see there is a "skip end lines" option so I just set that to the number of summary lines and... wait, now _all_ my transactions are gibberish? What happened? Turns out changing the number of skipped end lines resets all the options for CSV fields, date format, and amount options. This actually happens for all the options that changes the number of lines or how they're split (`delimiter`, `skip start lines`, `skip end lines`, and `file has header row`). This actually makes a lot of sense for the other three, since they will change the first line that is used to determine the column names that you select for the CSV fields options, so then the options you selected from before are no longer valid and will have to be reset. But the `skip end lines` doesn't change this first line unless you select a number greater than the number of rows (in which case there are no lines left at all, so it should be obvious that this was a mistake). Because the bottom lines are hidden from view if there are a lot of transactions it's easy to not notice you even need to ignore lines before you start selecting fields. And because so many fields are reset, it's really annoying to have to redo all of them, leading to an all around bad user experience. **Expected behaviour:** Changing `skip end lines` just removes some transactions from the end of the list without changing any other transactions. **Actual behaviour:** Changing `skip end lines` resets all CSV options selected, messing up all the remaining transactions and forcing you to redo your work. Observed on version 26.5.2 ### How can we reproduce the issue? 1. Go to an account 2. Click the `Import` button 3. Select any CSV file 4. Change any option under `CSV FIELDS`, `DATE FORMAT` or `AMOUNT OPTIONS`, for example click the `Flip amount` checkbox to True 5. Change the number in the `Skip end lines` number input 6. Observe that the options you set before have now been reset, for example the `Flip amount` checkbox will now be false ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Firefox ### Operating System Linux
GiteaMirror added the bugtransaction import labels 2026-05-29 20:55:54 -05:00
GiteaMirror commented 2026-05-29 20:55:56 -05:00
Author
Owner
Copy Link

@andrebk commented on GitHub (May 11, 2026):

Doing a little more testing, it looks like this problem only occurs when doing an import for the first time on an account. For accounts that have done an import before, changing the number of skipped lines does not reset the other fields.

I poked around the code a little bit and have a hypothesis. I've included it below, but I'm not a react guy and have all of 30 minutes of experience with this code base so take this with a large grain of salt:

Click here for speculation

So it looks like there is a useEffect call that re-parses the file if any of parse options change, for example delimiter, header row, or skipped lines:

a95c0ad9b0/packages/desktop-client/src/components/modals/ImportTransactionsModal/ImportTransactionsModal.tsx (L438-L468)

In the parse function that is called, after parsing the file it will apply your saved preferences for different options, for example flipping the amount:

a95c0ad9b0/packages/desktop-client/src/components/modals/ImportTransactionsModal/ImportTransactionsModal.tsx (L384-L388)

But, the only place these preferences are saved is in the onImport function:

a95c0ad9b0/packages/desktop-client/src/components/modals/ImportTransactionsModal/ImportTransactionsModal.tsx (L692-L697)

Because preferences are only saved upon actually doing the import, when you are changing around settings and trying stuff out on your first import, any changes that cause a re-parse (like skipped end lines) will cause the default values to be loaded for the field options (which looks like a reset).

Like here, where if prefs does not contain a setting for mappings it will call getInitialMappings and reset the fields:

a95c0ad9b0/packages/desktop-client/src/components/modals/ImportTransactionsModal/ImportTransactionsModal.tsx (L391-L397)

<!-- gh-comment-id:4424263276 --> @andrebk commented on GitHub (May 11, 2026): Doing a little more testing, it looks like this problem only occurs when doing an import for the first time on an account. For accounts that have done an import before, changing the number of skipped lines does not reset the other fields. I poked around the code a little bit and have a hypothesis. I've included it below, but I'm not a react guy and have all of 30 minutes of experience with this code base so take this with a large grain of salt: <details> <summary>Click here for speculation</summary> So it looks like there is a `useEffect` call that re-parses the file if any of parse options change, for example delimiter, header row, or skipped lines: https://github.com/actualbudget/actual/blob/a95c0ad9b0c78826ddc406368bbdcfdeb8041751/packages/desktop-client/src/components/modals/ImportTransactionsModal/ImportTransactionsModal.tsx#L438-L468 In the `parse` function that is called, after parsing the file it will apply your saved preferences for different options, for example flipping the amount: https://github.com/actualbudget/actual/blob/a95c0ad9b0c78826ddc406368bbdcfdeb8041751/packages/desktop-client/src/components/modals/ImportTransactionsModal/ImportTransactionsModal.tsx#L384-L388 But, the only place these preferences are _saved_ is in the `onImport` function: https://github.com/actualbudget/actual/blob/a95c0ad9b0c78826ddc406368bbdcfdeb8041751/packages/desktop-client/src/components/modals/ImportTransactionsModal/ImportTransactionsModal.tsx#L692-L697 Because preferences are only saved upon actually doing the import, when you are changing around settings and trying stuff out on your _first_ import, any changes that cause a re-parse (like skipped end lines) will cause the default values to be loaded for the field options (which looks like a reset). Like here, where if `prefs` does not contain a setting for mappings it will call `getInitialMappings` and reset the fields: https://github.com/actualbudget/actual/blob/a95c0ad9b0c78826ddc406368bbdcfdeb8041751/packages/desktop-client/src/components/modals/ImportTransactionsModal/ImportTransactionsModal.tsx#L391-L397 </details>
GiteaMirror commented 2026-05-29 20:55:57 -05:00
Author
Owner
Copy Link

@Hui66cs commented on GitHub (May 13, 2026):

I was able to reproduce this locally on the current master branch.

Changing Skip end lines causes the CSV import modal to re-parse the file and reset in-progress import settings. I reproduced this with Flip amount, and also with field mappings: after manually changing the Amount mapping and then changing Skip end lines, the mapping was restored to the inferred/saved value instead of preserving the current selection.

I’d like to work on a fix for this. My initial plan is to preserve the current in-progress import settings when skipEndLines changes, while still re-parsing the displayed rows.

<!-- gh-comment-id:4436916292 --> @Hui66cs commented on GitHub (May 13, 2026): I was able to reproduce this locally on the current `master` branch. Changing `Skip end lines` causes the CSV import modal to re-parse the file and reset in-progress import settings. I reproduced this with `Flip amount`, and also with field mappings: after manually changing the Amount mapping and then changing `Skip end lines`, the mapping was restored to the inferred/saved value instead of preserving the current selection. I’d like to work on a fix for this. My initial plan is to preserve the current in-progress import settings when `skipEndLines` changes, while still re-parsing the displayed rows.
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#100616
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?