Because different banks use the date fields in vastly different ways we
now let the server's bank integrations decide which date we should use.

Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>

* 1454 - Show projected balance when adding new transaction

* Release note

* Rename 1455.md to 1454.md

* Update release notes category

*  (eslint) add 'plugin:react/recommended'

* Release notes

*  (reports) fix incorrect cashflow balance

Fixing a small typo here where multiple transfers across different payees on the same day fail to be summed up resulting in significant balance errors.

* release notes

* Update 1518.md

* Fix re-rendering all rows on hover

* release note

* Removing isHover logic in place of css :hover

---------

Co-authored-by: biohzrddd <10577752+biohzrddd@users.noreply.github.com>

Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>

*  (reports) add loading indicators

* Release notes

Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>

This breaks fetching transactions where the valueDate is in the future.
While the GoCardless documentation says this should never happen, it's
what happens with at least Bank Norwegian due to them using the interest
date as valueDate.  (C.f. #1392)

Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>

Co-authored-by: Trevor Farlow <trevdor@users.noreply.github.com>

* ignore hidden categories

* release note

* Set `role="button"` on downshift autocomplete items
This avoids content observation behavior in WebKit on touch devices that delays the onClick event (and therefore reaction to user input).
* Disable split transaction editing for now

This is to prevent any further color changes added to PRs. This will
help prevent the darkTheme getting any addition work loaded onto it.

- web: https://github.com/actualbudget/actual/pull/1475
- server: https://github.com/actualbudget/actual-server/pull/240
- docs: https://github.com/actualbudget/docs/pull/260

The 'interval' value from the schedules is not set if the schedule is
monthly. This change will check for a valid number for the interval
value and if it does not exist will default to 1 (monthly).

Using the Apply Template or Overwrite option would result in
non-templated categories being overwritten. First reported :
https://discord.com/channels/937901803608096828/1137329898999001140/1137329898999001140

Closes #1328

Closes #1471

Making the `crdt` package fully TypeScript-strict.

References discord discussion starting here:
https://discord.com/channels/937901803608096828/940290142579605514/1133523705063030824

Currently the schedule keyword won't fill any future budget cells if the
category balance already satisfies the schedule. This PR is an attempt
to improve the behavior by allowing budget fills regardless of the
category balance.

This is a drastic rewrite of the schedule keyword. Though I've tried not
to have any regressions, it is possible because of how different the
logic is. I've tested compounding using a simple template, so a small
change in the 'by' keyword was also made.

Not much to this. Turns title bar from transparent to coincide with new
theme coloring.

fix #1445

Closes #1375

In some situations the text in the Select component will be too big,
which will make the inner vertical scrollbar appear. This PR is to hide
the vertical scrollbar.

![截圖 2023-08-04 下午3 06
38](https://github.com/actualbudget/actual/assets/67775387/be6c066d-de44-4944-b02e-5d265c84bc61)

Upgrading murmurhash. The new version has TS types.

Apart from that, it looks pretty much the same.

Diff: https://www.diffchecker.com/CEpBedX1

This PR has no functional changes. Only types are changing and getting
improved (more stricter).

A follow-up PR will come next that does a few functional changes to make
this package fully strict.

<!-- Thank you for submitting a pull request! Make sure to follow the
instructions to write release notes for your PR — it should only take a
minute or two:
https://github.com/actualbudget/docs#writing-good-release-notes -->

Addresses
https://github.com/actualbudget/actual/issues/1360#issuecomment-1646600087