A local-first personal finance system

cc @manuelcanepa — let me know if all of this makes sense for Spanish too :)

One thing I’m not super confident about is general.ordinal, but I’m not sure what the best approach for that is. (The Intl API doesn’t offer ordinal formatting for some reason)

Adds a very basic docker-compose file using Kovah's docker image of the server. Persists data via the volume mounting on $DOCKERDIR/actual/data:/data.

User should define $DOCKERDIR or set it to a relative path on the docker server.

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

When trying to import from YNAB 4, the importer goes to a blank white screen. There's no error message and no message in the browser's console.

What error did you receive?

Blank screen

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome, Microsoft Edge

Operating System

Windows 11

I searched and didn't find this, but forgive me if I missed it. It would be really handy if we could select a transaction and duplicate it so we could just change the date and be on our way. I'm thinking of transactions I have that have multiple splits and I repeat monthly. A big time saver.

Closes #90

Deps Changes

1. The babel transform to CommonJS for Jest (as I understand it) was failing. Seemed to be due to shifting deps versions, and bumping @babel/plugin-transform-modules-commonjs addressed it.
2. And of course, removed currency-formatter

Locale Change

Switch to en-ZA as our example locale for space-comma. (za-ZA does not exist. Might have been a typo for zu-ZA, but that is a comma-dot locale, to use Actual notation.)

Open Questions

Is this the best way to fix to 2 decimal places?

• Usually, the currency param to NumberFormat would dictate the minimumFractionDigits/maximumFractionDigits values, but we're avoiding setting a specific currency (along with the currency symbol that brings).
• As far as I understand, nearly every currency worldwide (though not 100% of them) uses 2 fractional digits. I'd argue it's safe to fix to 2 at least for our purposes, but open to being convinced otherwise.

Show 'n' Tell

Before (currency-formatter) --> After (Intl.NumberFormat as configured in this PR)

Introduction

This is a request for comment (RFC) on if client-side encryption should be sunset in Actual OSS.

Actual clients support syncing between many instances using a centralized server (sync server). As clients make modifications, the changes to their internal state are set to the sync server to be received and applied by other individual client instances.

Further, under Actual (in the before times), the client supported encrypting all data locally before the data was sent to the sync server, as documented here (end-to-end-encryption).

Effectively, client side encryption allows for a zero-trust model for the syncing server. The end-user could assume both the data was encrypted on disk in a format that even the operator of the server would not be able to access.

Terminology

When I refer to the sync server, I refer to a hypothetical server that only handles syncing of encrypted data between clients. The OSS server is functionally different from the previous implementation.

When I refer to a client, I refer to the full-fat clients in the model of the before times Actual e.g. the Mobile client and the Electron Desktop client. The OSS server blurs the lines.

Proposal

In Actual OSS, servers are hosted and maintained by the same individuals using the Actual OSS client. These individuals may employ full-disk encryption or other security measures if they believe such protections are warranted. Since there is no longer a third-party operator who may have access to the Actual data, the zero-trust model is less useful.

Client-side encryption should be considered for removal from Actual OSS.

Pro Removal

• The original security concerns are moved to individuals, allowing them to choose their threat model.
• Not only is this client-encryption less useful, the encryption introduces additional complexities:
  • Additional error checking is required.
  • Additional API surface area needs to be maintain.
  • Multiple logic flows (encrypted and unencrypted) would need to be tested and maintained.
  • The server is unable to modify the Actual data without the involvement from a client. This may make largely desired features, such as automatic bank import, more difficult.
  • etc.
• Encryption is currently not supported by the OSS server per this comment: https://github.com/actualbudget/actual-server/blob/44d045f546ceb2440f2a681bc5821bbb8eefb80f/app-sync.js#L126-L135 Additional work will be required to support client-side encryption.

Against Removal

• Some individuals may not have the technical ability to secure a server effectively (e.g. full disk encryption is only useful with physically protected, physical hardware, which may be out of scope for many). Services like https://fly.io/ should be considered as the lowest common denominator that should still support a secure encryption model.
• Client side encryption is a features that is best added at the beginning of development. The code largely already exists and should be maintained.
• If a community maintained cloud service is every considered again (similar to https://www.home-assistant.io/cloud/), client-side encryption would be largely desirable.

Commentary

• I personally found this client-side encryption feature a major factor in ultimately selecting Actual for personal use. I still believe client-side encryption is a killer feature.
• I personally run full-disk encryption on my own infrastructure, and while I support the inclusion of any time of client-side encryption (and would actively use it), the developer side of me likes the idea of being able to modify Actual data from the server without a client (aka a developer API). I would want to prioritize features like Plaid fetching or stock value tracking over client-side encryption - as I personally can secure the Actual data in a way that is acceptable.

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

Pressing return/enter when focused on the payment/deposit columns of a new transaction will cause the transaction to be added/saved. However, this will not happen for the “cleared” checkbox.

What error did you receive?

No response

Where are you hosting Actual?

Locally via Yarn

What browsers are you seeing the problem on?

Chrome, Safari

Operating System

Other

If I import a YNAB4 budget from zip file in Firefox 99.0.1 on Windows 19043, I get the error

Your data is out of sync
There was a problem syncing your data. We can try to repair your sync state to fix it. [Learn more](https://actualbudget.com/docs/overview/syncing-across-devices/#debugging-sync-issues)

If I click Repair I get the error

Your data is still out of sync
We were unable to repair your sync state, sorry! You need to reset your sync state. [Learn more](https://actualbudget.com/docs/overview/syncing-across-devices/#debugging-sync-issues)

If I click Reset sync and refresh the page, the first dialog is shown again. After I refreshed the page, my budget was lost and a previously deleted budget has taken its place.

When an income item is in the register with a date in the future reconciling the account includes this income even though the date has not yet passed.

The account balance also shows that the income value that was entered in the register is in the account balance - should it not be included in the register and added to the balance and available for reconcile once the date of the transaction is true?

Create new CircleEmpty svg and set uncleared state to use new icon.

Add 'cursor: pointer' to the cleared field to aid in action awareness.

See discussion https://github.com/actualbudget/actual/discussions/271 for initial thoughts around the problem and the solution.

Uncleared transactions have a hollow circle. Cleared transactions maintain the existing filled background checkmark. cleared field now gains a pointer on hover to show interactivity option

See image of this solution.

Mobile application is unchanged. Given the direction seems to be deprecating the mobile app, I assumed I could skip changing there. Please let me know if I should update it anyway, or if there are any other issues!

I personally find the imports quite hard to manage (particularly in desktop-client) as we have a jumble of external imports, imports from other workspaces in the monorepo and local imports all mixed together. This means it's quite hard to see what what's going on and what exactly the open file depends on. Now that Actual is OSS, there's more cooks in the kitchen so it will likely deteriorate further.

To fix this I've added a plugin to the linter which enforces that imports are sorted consistently and will automatically fix deviations from this.

Specifically, we now sort imports as:

1. React related packages
2. External packages
3. Monorepo packages
4. Local imports

Each group is separated with a newline and within each group the imports are sorted alphabetically.

Re-enabling and fixing skipped unit tests.

Before:

➤ YN0000: [loot-core]: Test Suites: 4 skipped, 32 passed, 32 of 36 total
➤ YN0000: [loot-core]: Tests:       33 skipped, 210 passed, 243 total
➤ YN0000: [loot-core]: Snapshots:   40 passed, 40 total
➤ YN0000: [loot-core]: Time:        131.646 s

After:

➤ YN0000: [loot-core]: Test Suites: 1 skipped, 35 passed, 35 of 36 total
➤ YN0000: [loot-core]: Tests:       2 skipped, 241 passed, 243 total
➤ YN0000: [loot-core]: Snapshots:   69 passed, 69 total
➤ YN0000: [loot-core]: Time:        145.029 s

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

See below video. In accounts: Filter > Date > Change Date to Month > RangeError

Additionally, we should be consistent in the date format used for filtering Date, Month and Year and converting between them should pick a sane value based on the previous selection. Currently Date: yyyy/mm/dd Month: mm/yyyy Year:

Ideally Date: yyyy/mm/dd Month: yyyy/mm Year: yyyy

https://user-images.githubusercontent.com/10577752/209000486-d58d8652-0b6b-43c9-a60a-7151f1957610.mp4

What error did you receive?

RangeError: Invalid time value format node_modules/date-fns/esm/format/index.js:363

360 | var originalDate = toDate(dirtyDate); 361 | 362 | if (!isValid(originalDate)) {

363 | throw new RangeError('Invalid time value'); | ^ 364 | } // Convert the date in system timezone to the same date in UTC+00:00 timezone. 365 | // This ensures that when UTC functions will be implemented, locales will be compatible with them. 366 | // See an issue about UTC functions: https://github.com/date-fns/date-fns/issues/376

Where are you hosting Actual?

Locally via Yarn

What browsers are you seeing the problem on?

Firefox

Operating System

Windows 10

Importing a file wasn't obvious after already starting a test budget. This PR adds Import to the Settings > File menu, includes a brief explanation of the process, and copies the "Sign out" button. Explanation added for Export as well.

Verified issue does not already exist?

I have searched and found no existing issue

What happened?

When importing a YNAB4 budget with scheduled transactions (some accounts with them and some without) that haven't been added to the register, none of the scheduling transfers (in Actual, going to Schedules shows "No schedules").

What error did you receive?

None

Where are you hosting Actual?

Locally via Yarn

What browsers are you seeing the problem on?

Firefox

Operating System

Windows 10