Skip to content
Snippets Groups Projects
user avatar
Julian Dominguez-Schatz authored
* Add split creation UI to rule creation modal

* Support applying splits when rules execute

* fix: deserialize transaction before running rules

According to how rules are run in other places in the app, we should be
supplying a "deserialized" (i.e., integer-for-amount and ISO date)
transaction rather than a "serialized" (amount-plus-formatted-date) one.
This fixes a crash in how split transactions are applied, as well as
date-based rules not applying correctly previously (any rule with a date
condition would never match on mobile).

* Add release notes

* Fix missing types pulled in from master

* PR feedback: use `getActions`

* PR feedback: use `flatMap`

* Fix action deletion

* Don't flicker upon split deletion

* Let users specify parent transaction actions (e.g. linking schedules)

* Support empty splits

* Revert adding `no-op` action type

* Support splits by percent

* Fix types

* Fix crash on transactions page when posting a transaction

The crash would probably have occurred in other places too with
auto-posting schedules :/

* Fix a bug where schedules wouldn't be marked as completed

This was because the query that we previously used didn't select parent
transactions, so no transaction was marked as being scheduled (since
only parent transactions have schedule IDs).

* Add feature flag

* Limit set actions within splits to fewer fields

* Fix merge conflict

* Don't run split rules if feature is disabled

* Fix percent-based splits not applying

* Fix crash when editing parent transaction amount

* Auto-format

* Attempt to fix failing tests

* More test/bug fixes

* Add an extra split at the end if there is a remaining amount

* Make sure split has correct values for dynamic remainder

* Remove extraneous console.log
2bb7b3c2
History

Actual on the web

E2E tests

E2E (end-to-end) tests use Playwright. Running them requires an Actual server to be running either locally or on a remote server.

Functional

Running against the local server:

# Start the development server
yarn start

# Run against the local server (localhost:3001)
yarn e2e

Running against a remote server:

E2E_START_URL=http://my-remote-server.com yarn e2e

Visual regression

Visual regression tests (also known as screenshot tests) check that the visual appearance of the product has not regressed. Each environment has slightly different colors, fonts etc. Mac differs from Windows which differs from Linux. In order to have a stable test environment for visual comparisons - you must use a standartised docker container. This ensures that the tests are always ran in a consistent environment.

Prerequisites:

  • Docker installed

Running against the local server

First start a dev instance:

HTTPS=true yarn start

or using the dev container:

HTTPS=true docker compose up --build

Note the network IP address and port the dev instance is listening on.

Next, navigate to the root of your project folder, run the standartised docker container, and launch the visual regression tests from within it.

# Run docker container
docker run --rm --network host -v $(pwd):/work/ -w /work/ -it mcr.microsoft.com/playwright:v1.41.1-jammy /bin/bash

    # If you receive an error such as "docker: invalid reference format", please instead use the following command:
    docker run --rm --network host -v ${pwd}:/work/ -w /work/ -it mcr.microsoft.com/playwright:v1.41.1-jammy /bin/bash

# Run the VRT tests: important - they MUST be ran against a HTTPS server.  Use the ip and port noted earlier
E2E_START_URL=https://ip:port yarn vrt

    # To update snapshots, use the following command:
    E2E_START_URL=https://ip:port yarn vrt --update-snapshots

Running against a remote server

You can also run the tests against a remote server by passing the URL:

E2E_START_URL=https://my-remote-server.com yarn vrt