Refactored all feature flags to use the new `useFeatureFlag` hook.
Also added a new functionality to this feature flag: ability to define
custom "default" value for a feature flag. This will allow us to enable
the new autocomplete component for everyone using Netlify builds
eventually (need to address some issues before doing so).
Further iterations on the new autocomplete.
1. Created `AccountAutocomplete`
2. Started using new autocomplete in `GenericInput` (used for notes
field)
3. Extracted common functionality between the three new autocompletes to
a generic component: `Autocomplete`
I noticed that the first run flow is suboptimal for people who want to
import an existing file from Actual/YNAB. I’ve moved the welcome modal
into the management app and set it up to appear when there are no
budgets available (which also has the benefit of allowing people to see
the modal again!)
I think there’s some weirdness around getting the modal to reappear when
deleting a budget file which I want to work out before merging this.
This PR also reorganizes the management app a bit to reduce usage of
modals (currently, hitting escape while the budget list is open leaves
you with a blank page).
<img width="539" alt="Screenshot_2023-03-18 08 53 54"
src="https://user-images.githubusercontent.com/25517624/226107462-b2b88791-1015-4397-b290-c64e7fcc0f41.png">
- [x] Ensure modal consistently appears when needed (no longer a modal!)
- [x] Fix e2e tests
Added an extra `waitFor` after a flaky unit test step.
I'm not really super happy with this workaround.. but it does make the
test much more stable (re-ran 5x and no failures:
https://github.com/actualbudget/actual/actions/runs/4455134799).
I think there is some internal timeout happening somewhere which is
causing this issue.. But not really sure where. And this will hopefully
get auto-fixed once we migrate to a new table. 🤞
This is not a full fix for the flakiness. One of the test cases will
still be flaky. But at least this fixes the other test cases thus
improving stability.
I am currently not working on adding support for importing to multiple
accounts, but I wanted to give anyone who takes that on a starting point
by updating the underlying C library to provide access to the account
name field.
Tests cases should be independent. You should be able to run them in
whatever order you want. And they should still pass.
Currently this is not the case. The order of the tests is very important
due to the "pseudo" randomization algorithm.
This PR makes the mock data IDs truly unique thus better exposing the
issue in our tests. Also this PR fixes the dependency issues thus making
each test case truly independent.
---------
Co-authored-by: Jed Fox <git@jedfox.com>
See https://github.com/actualbudget/docs/pull/129 for more details. If
this is accepted, I’ll fill in release notes for the PRs that have been
submitted since the last release and submit a corresponding PR to
`actual-server`.
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
before:
```
kcab.worker.4bdc73a8d45eb2115156.js (2.1 MiB)
xfo.kcab.worker.4bdc73a8d45eb2115156.js (1010 KiB)
```
after:
```
kcab.worker.39f5fba82d7bc7477962.js (1.41 MiB)
xfo.kcab.worker.39f5fba82d7bc7477962.js (1000 KiB)
```
What’s changed:
- `loot-core` did not have a `browserslist` config, so
`@babel/preset-env` assumes we want to [transpile all the way back to
ES5](https://babeljs.io/docs/options#no-targets). I’ve removed the
`browserslist` config from each of the `package.json` files and moved it
to the root so this doesn’t happen again.
- I updated the target from `electron 3.0` to `electron 12.0` to match
our Electron dependency
- I’ve added `defaults` (currently equivalent to `> 0.5%, last 2
versions, Firefox ESR, not dead`) which is [recommended by
browserslist](https://browsersl.ist/#q=defaults). We could consider
tightening this, but it doesn’t offer a ton of space savings at this
point to just target Electron 12.
- Since much less transpilation will be happening, stack traces (dev and
prod) will be much easier to read!
I recently migrated my personal usage of Actual over to the open-source
version and imported a bunch of transactions. I have a _lot_ of history
in Actual, including a lot of weird edge cases like deleted split
transactions. While reconciling I noticed that my account balance shown
at the top was incorrect, even though the running balance was current.
Digging into this, I discovered that we aren't correctly handling
aggregate queries when querying transactions in the "grouped" mode.
Aggregate queries don't make sense in the "grouped" mode. Grouped means
that you want a list of transactions that include both the parent and
child transactions (when they are split). If you are summing up all the
amount, you only want to consider non-parent transactions. So we switch
it back to "inline" mode, but the way we did this previously was to
manually stitch the query together.
Even though was add SQL to ignore deleted transactions, we still
possibly include them. A child transaction may not be marked as deleted,
even though the parent transaction is deleted. When a parent transaction
is deleted, all child transactions should be considered deleted as well,
regardless of their tombstone status. This is what the
`v_transactions_internal_alive` view does. Previously we weren't going
through this view though, so we could still potentially include split
transactions even though they've been deleted.
This is little hacky, but it fixes the immediate problem. We fall back
to the inline mode by modifying the where clause, and we also adjust the
view that it queries to use the correct one.
Check if the transaction amount is a positive 0 rather than -0.
I went for casting the string with `Number` but I could instead replace
the whole condition with `!trans.amount.startsWith('-')` or with
`trans.amount > 0 || trans.amount == '0.00'` if either of these variants
are preferred.
Fix for
https://github.com/actualbudget/actual/issues/724#issuecomment-1464907064
This implements a simple indicator showing the user if the currently
used version is outdated by utilising GitHub tags to track the latest
version.
Closes#463
---------
Co-authored-by: Jed Fox <git@jedfox.com>
* Update gitignore about .idea folder
The .idea folder is generated by IntelliJ IDEA
* Add integration with Nordigen
* Fix linter
* Use longer access to the account
* Move normalizatoin of accounts to the backend side
* Fix possibility to force remove account
* Move normalization of transactions to the backend side
* Fix Settings.js after merge
* fix enableing bank sync
* delete old Settings component
* Use camelCase for nordigen/remove-account call
* WIP refactor
* Fix auto-selecting existing accounts
* Fix unlinking accounts
* Align to backend changes for Nordigen integration
* Fix AnimatedLoading
* Code review changes
* Fix TZ date issue
* rm mobile package
* rm BankSync settings section
* rm console.log
* rm comment
* applies some alignments from code review
* applies some alignments from code review
* Add prefix for nordigen specific functionality
* Use arrow char
* Add prefix for nordigen functionalities
* Fix linter
* Display only open accounts
* Update packages/desktop-client/src/nordigen.js
Co-authored-by: Jed Fox <git@jedfox.com>
* Fix incorrect calc of TZ for endDate
* Improved error checking
* Fix throwing invalid-schema error
* Fix for syncing large batches in Safari
---------
Co-authored-by: Filip Stybel <filip.stybel@ynd.co>
Co-authored-by: Leon Ebel <24588023+ebelleon@users.noreply.github.com>
Co-authored-by: Jed Fox <git@jedfox.com>
* Intelligently adjust field for newly added action
* Remove unnecessary switch case
* Dedupe list of fields
* Remove unnecessary conditionFields prop
* Intelligently adjust field for newly added condition
* Use a less specific condition
