Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feedback]: SimpleFIN Sync #2272

Closed
zachwhelchel opened this issue Jan 22, 2024 · 203 comments · Fixed by #3459
Closed

[Feedback]: SimpleFIN Sync #2272

zachwhelchel opened this issue Jan 22, 2024 · 203 comments · Fixed by #3459
Labels
bank sync Related to automatic bank syncing experimental feature Related to an experimental feature feedback Single feedback thread for bug reports on a new feature

Comments

@zachwhelchel
Copy link
Contributor

zachwhelchel commented Jan 22, 2024

This issue is to track thoughts/bugs/concerns/ideas around the new SimpleFIN syncing which is an experimental feature.

@zachwhelchel zachwhelchel added the bug Something isn't working label Jan 22, 2024
@zachwhelchel zachwhelchel changed the title [Bug]: [Feedback]: SimpleFIN Sync Jan 22, 2024
@MatissJanis MatissJanis added experimental feature Related to an experimental feature feedback Single feedback thread for bug reports on a new feature bank sync Related to automatic bank syncing and removed bug Something isn't working experimental feature Related to an experimental feature labels Jan 22, 2024
@MatissJanis MatissJanis pinned this issue Jan 22, 2024
@JMLegere
Copy link

How do I use this?

@youngcw
Copy link
Member

youngcw commented Jan 23, 2024

@JMLegere Currently you have to be using the edge release, then enable the experimental feature for it

@sethgillett
Copy link
Contributor

sethgillett commented Jan 26, 2024

Any concerns about how actively developed their bridge tool is? Their last blog post is from 2016 and their terms of use haven't been updated since 2020, and it doesn't seem like any banks have implemented the protocol themselves.

Edit: It looks like their privacy policy was updated last October.

@youngcw
Copy link
Member

youngcw commented Jan 26, 2024

@sethgillett SimpleFIN uses MX in the background and its primary role is to make bank sync accessable to individuals instead of having to use a large company service. So there likely isn't much that needs changed. From what I've heard the guy that runs it is very responsive and actively keeping it going.

@yoyotogblo
Copy link
Contributor

He's very responsive. Almost always responds within a few hours of issues being raised and escalates issues quickly also. I won't be concerned about it being active.

@joel-jeremy
Copy link
Contributor

We should add a new feature to "force match" an existing transaction to a newly imported one. This should basically just assign the imported_id of the new imported transaction to an existing transaction. This way when the next sync runs, the existing transaction will be matched and will not be duplicated.

@yoyotogblo
Copy link
Contributor

We should add a new feature to "force match" an existing transaction to a newly imported one. This should basically just assign the imported_id of the new imported transaction to an existing transaction. This way when the next sync runs, the existing transaction will be matched and will not be duplicated.

That's how it already works. If the imported_id exists, it auto-matches so doesn't dupe. If it doesn't exist, it uses fuzzy matching
(looks at transactions 4 days prior and 1 day after the imported transactions) and if it finds one, it assigns that existing the transaction the imported_id.

@joel-jeremy
Copy link
Contributor

I'm aware of that, and what I meant is for users to be able to do what the fuzzy matching is doing by manually selecting which transactions to "match". Because the fuzzy matching will not be able to catch all the cases - in my case, the bank seems to use the cleared date as the transaction date instead of the date the purchase was made and that varies between 1 day or sometimes a week.

Another thing I noticed is that the imported transactions doesn't seem to match split transactions.

@cmccambridge
Copy link

The fuzzy logic (-4 to +1 days) makes sense when syncing of all accounts is happening on an on-going daily basis, and we hope that most transactions appear in chronological order across acounts. But, it's been a problem tonight as I'm trying out new SimpleFIN links to existing Actual accounts...

Is there a reason to keep the match range asymmetric? Could it be updated to -4 to +4, for example? Else definitely the "force match" concept that @joel-jeremy mentioned would resolve my case as well... I had gone looking for that exact feature at first, but couldn't find it.

Here's the problematic scenario for my data:

  1. Local checking account existed. Local credit card account existed.
  2. On a past date (typically my problem is near a weekend when credit card and bank disagree on effective dates), a payment was made from my checking account to the credit card.
  3. Previously, using QXF imports, the Checking account recorded the transfer on, for example, Nov 6, 2023 (a Monday). The credit card recorded it on Nov 3, 2023 (a Friday).
  4. I dealt with the duplicate/non-matched transactions by deleting one or the other, depending which account I happened to import via QXF first to trigger the transfer Rules.
  5. In future updates, I avoided the problem by using "last 30 days" type QXF files to dodge the duplicates
  6. When I linked the checking account to SimpleFIN, all was well: Fuzzy match worked and the payment on Nov 6 looked good from the checking account side.
  7. When I linked the credit card to SimpleFIN, it imported the Nov 3 payment again, and the fuzzy match failed, presumably since the real transfer on Nov 6 was too far into the future.
  8. I deleted the new Nov 3 payment manually, synced again, and the SimpleFIN sync recreated it ☹️.

I think the better workaround as I identify these date collisions is for me to go change the dates of the transfer to try and favor the earlier date?

But, the manual work to figure out which account I need to forcibly tweak is overhead that would be great to avoid if possible 😄

@yoyotogblo
Copy link
Contributor

I'm aware of that, and what I meant is for users to be able to do what the fuzzy matching is doing by manually selecting which transactions to "match". Because the fuzzy matching will not be able to catch all the cases - in my case, the bank seems to use the cleared date as the transaction date instead of the date the purchase was made and that varies between 1 day or sometimes a week.

Another thing I noticed is that the imported transactions doesn't seem to match split transactions.

Ah yeah, manually matching...

I wrote a lot of details about the ideal behavior in the issue below... Fully agree that we need a way to manually match.
#669

Also, on the 1 day vs a week time difference, I have a PR.to change the fuzzy matching logic to 7 days prior and 7 days after. I use that in my instance and it works much better.
#2300

@yoyotogblo
Copy link
Contributor

yoyotogblo commented Feb 1, 2024

The fuzzy logic (-4 to +1 days) makes sense when syncing of all accounts is happening on an on-going daily basis, and we hope that most transactions appear in chronological order across acounts. But, it's been a problem tonight as I'm trying out new SimpleFIN links to existing Actual accounts...

Is there a reason to keep the match range asymmetric? Could it be updated to -4 to +4, for example? Else definitely the "force match" concept that @joel-jeremy mentioned would resolve my case as well... I had gone looking for that exact feature at first, but couldn't find it.

Here's the problematic scenario for my data:

  1. Local checking account existed. Local credit card account existed.
  2. On a past date (typically my problem is near a weekend when credit card and bank disagree on effective dates), a payment was made from my checking account to the credit card.
  3. Previously, using QXF imports, the Checking account recorded the transfer on, for example, Nov 6, 2023 (a Monday). The credit card recorded it on Nov 3, 2023 (a Friday).
  4. I dealt with the duplicate/non-matched transactions by deleting one or the other, depending which account I happened to import via QXF first to trigger the transfer Rules.
  5. In future updates, I avoided the problem by using "last 30 days" type QXF files to dodge the duplicates
  6. When I linked the checking account to SimpleFIN, all was well: Fuzzy match worked and the payment on Nov 6 looked good from the checking account side.
  7. When I linked the credit card to SimpleFIN, it imported the Nov 3 payment again, and the fuzzy match failed, presumably since the real transfer on Nov 6 was too far into the future.
  8. I deleted the new Nov 3 payment manually, synced again, and the SimpleFIN sync recreated it ☹️.

I think the better workaround as I identify these date collisions is for me to go change the dates of the transfer to try and favor the earlier date?

But, the manual work to figure out which account I need to forcibly tweak is overhead that would be great to avoid if possible 😄

I have a PR to make it symmetrical and to use 7 days in both cases...
#2300

I had the same issues as you with the Simplefin sync and this has solved it. BTW, currently, the Simplefin sync looks back 90 days. Most accounts don't provide that much history so you won't see as many breaks. But for the ones that do, it could break over a 90 day range everytime you sync.

@joel-jeremy
Copy link
Contributor

Another observation: This is not SimpleFIN specific but when you modify an imported transaction, it will still match the next time you sync even though the fields are no longer the same. I think we should treat imported transactions like we do reconciled transactions where a warning pops up when editing an imported transaction.

@cmccambridge
Copy link

This one might be SimpleFIN specific, and might also not be fixable depending what data we have to work from, but I'll ask :)

Is there any additional metadata we can present on the Link UX flow to help clarify what's what in the available SimpleFIN connections? In my connections, some appear to use the "friendly name" i set through the bank UI, or a common name for the card, but others are very generic and I could only figure out which account it was through process of elimination. On one I even had to guess, realize it was wrong, delete the imported transactions, and try again :)

Is there any connection name we could show? Or a partial account number to disambiguate multiple similar-named accounts?
image

@MatissJanis
Copy link
Member

👋 I tried setting up simplefin to run some tests. Here are some issues I encountered:

  • we definitely need a docs page; similar to the one we have for gocardless
  • there is no way to set a new token (initially I used an invalid token; this causes the /accounts request to load forever without any way to replace this invalid token with something else); -- maybe there actually is a way to update the token.. but I'm not able to get to it
  • could we add a "use test credentials" button that uses the test secret (from here) if folks are running a dev server? Would make testing it much quicker
  • it seems that the notes field is always the same as payee field: is that expected (I'm using the above test credentials)?

Everything else seems to be working good so far. Great job!

@swelborn
Copy link

swelborn commented Feb 1, 2024

Hello! It may be good to have a marker to designate transactions that were imported through syncing with simplefin. I may be missing this if it is there. Ideally, one could toggle that marker off/on depending on if they wanted it there or not.

all around awesome and seamless. Need to do a bit of rule updating, but other than that all of my accounts are synced up. great work.

@joel-jeremy
Copy link
Contributor

joel-jeremy commented Feb 1, 2024

It may be good to have a marker to designate transactions that were imported through syncing with simplefin

This is a good idea. We mark linked/imported accounts in the UI and we should do the same with imported transactions (gocardless/simplefin) IMO. This + warn users if an imported transaction is being modified. If modified, it should then be converted to a regular transaction (we remove it's imported_id).

@yoyotogblo
Copy link
Contributor

Another observation: This is not SimpleFIN specific but when you modify an imported transaction, it will still match the next time you sync even though the fields are no longer the same. I think we should treat imported transactions like we do reconciled transactions where a warning pops up when editing an imported transaction.

This is how I'd expect it to work though. It matches the imported id and since it recognizes that you've already imported that transaction and edited it, it shouldn't try to change it and should just match it. Not sure of the benefit of a warning pop up in this instance.

@yoyotogblo
Copy link
Contributor

This one might be SimpleFIN specific, and might also not be fixable depending what data we have to work from, but I'll ask :)

Is there any additional metadata we can present on the Link UX flow to help clarify what's what in the available SimpleFIN connections? In my connections, some appear to use the "friendly name" i set through the bank UI, or a common name for the card, but others are very generic and I could only figure out which account it was through process of elimination. On one I even had to guess, realize it was wrong, delete the imported transactions, and try again :)

Is there any connection name we could show? Or a partial account number to disambiguate multiple similar-named accounts? image

There's definitely more info that can be shown... If you use the external test script that Dup created, that has more info. I ran into the same thing and played the same guessing game and deleting transactions. Good thing is you only have to do it one time :)!

@yoyotogblo
Copy link
Contributor

It may be good to have a marker to designate transactions that were imported through syncing with simplefin

This is a good idea. We mark linked/imported accounts in the UI and we should do the same with imported transactions (gocardless/simplefin) IMO. This + warn users if an imported transaction is being modified. If modified, it should then be converted to a regular transaction (we remove it's imported_id).

Definitely don't think we should ever be removing the imported_id. Based off your proposal, if it imports a transaction and I need to change the payee, then that's now modified. Remove the imported_id and the transaction gets duped. Not sure I see any benefit to what you're proposing.

@swelborn
Copy link

swelborn commented Feb 2, 2024

In terms of the marker, I was only thinking of a label like your green dots next to the linked accounts. I don't think this would involve removing a uid as suggested above, but adding a tag... but I'm not familiar with source so I'm not sure how difficult this would be.

I am checking actual from mobile now and there is no sync button. I understand that the mobile version is not as fully featured as desktop, but a sync button would be good for mobile.

@joel-jeremy
Copy link
Contributor

This is how I'd expect it to work though. It matches the imported id and since it recognizes that you've already imported that transaction and edited it, it shouldn't try to change it and should just match it. Not sure of the benefit of a warning pop up in this instance.

I am referring to user-made edits not edits made by the importer if that's what your thinking.

Definitely don't think we should ever be removing the imported_id. Based off your proposal, if it imports a transaction and I need to change the payee, then that's now modified. Remove the imported_id and the transaction gets duped. Not sure I see any benefit to what you're proposing.

The warning popup can be limited to amount user edits or possibly even the date. It doesn't make sense to have an imported transaction's amount be different from the amount that came from the bank. It can also introduce confusion when users need to reconcile old transactions.

@endigma
Copy link

endigma commented Aug 11, 2024

I think SimpleFIN has some sort of rate limit that Actual doesn't obey when there's many accounts.

Their API starts returning 429 after some requests but doesn't have a Retry-After header which complicates things.

This consistently makes syncing on some of my accounts fail as when doing "sync all" they are ordered after the rate limiting starts.

@duplaja
Copy link
Contributor

duplaja commented Aug 11, 2024

There's a WIP pull request to sync multiple SimpleFIN accounts in a single API call. I believe it still has the front-end part to do, but that should help take care of the issue. actualbudget/actual-server#384

@jrgiacone
Copy link

jrgiacone commented Aug 11, 2024

Curious if there’s any way to have an approval tag or for approval on simplefin imported transactions for review to know what is imported

@psybers
Copy link
Contributor

psybers commented Aug 11, 2024

Curious if there’s any way to have an approval tag or for approval on simplefin imported transactions for review to know what is imported

Reconcile those accounts periodically. Then anything imported is not reconciled and you can check them.

@Towerism
Copy link

@psybers the simplefin_token is saved correctly. simplefin_accessKey is NULL.

@psybers I finally got around to trying a fresh install of actual. I was able to get the simplefin accesskey working on the fresh install. However, if I imported my actual data from my main instance, now I have the issue that I described before. I'm not sure where to go from here in terms of troubleshooting. If you could tell me where I can go from here it would be much appreciated.

@psybers
Copy link
Contributor

psybers commented Aug 16, 2024

@psybers the simplefin_token is saved correctly. simplefin_accessKey is NULL.

@psybers I finally got around to trying a fresh install of actual. I was able to get the simplefin accesskey working on the fresh install. However, if I imported my actual data from my main instance, now I have the issue that I described before. I'm not sure where to go from here in terms of troubleshooting. If you could tell me where I can go from here it would be much appreciated.

@Towerism You should click on add account, then next to the simple fin button there is a button with 3 dots. Click that and reset your credentials.

Then go back in and use a brand new setup token and things should start working.

@Towerism
Copy link

@psybers the simplefin_token is saved correctly. simplefin_accessKey is NULL.

@psybers I finally got around to trying a fresh install of actual. I was able to get the simplefin accesskey working on the fresh install. However, if I imported my actual data from my main instance, now I have the issue that I described before. I'm not sure where to go from here in terms of troubleshooting. If you could tell me where I can go from here it would be much appreciated.

@Towerism You should click on add account, then next to the simple fin button there is a button with 3 dots. Click that and reset your credentials.

Then go back in and use a brand new setup token and things should start working.

Sadly this did not work. It's the same outcome as before. There's gotta be something about my actual data on the server that is screwing this up. I just don't know what it is.

@csobrinho
Copy link

Hi folks, trying to run the SimpleFIN integration. I've noticed that sometimes I can't sync or see the accounts and if I wait a few minutes then I can see the account list again but sync is still broken. It was working great but then it stopped. Not sure if I have too many accounts (12 banks, +-20 accounts) or running into some sort of rate limit or caching?

Also, shouldn't the SimpleFIN token (inside server-files/account.sqlite) be encrypted? Thanks!!

@csobrinho
Copy link

Sent the request manually and got:

{"errors":["Too many requests. SimpleFIN data is only refreshed once every 24 hours. Expected usage of this API is 1 request per hour."],"accounts":[]}/app #

This kinda breaks the model in case you add an account and trigger a sync each time :(

@Towerism
Copy link

@psybers the simplefin_token is saved correctly. simplefin_accessKey is NULL.

@psybers I finally got around to trying a fresh install of actual. I was able to get the simplefin accesskey working on the fresh install. However, if I imported my actual data from my main instance, now I have the issue that I described before. I'm not sure where to go from here in terms of troubleshooting. If you could tell me where I can go from here it would be much appreciated.

@Towerism You should click on add account, then next to the simple fin button there is a button with 3 dots. Click that and reset your credentials.
Then go back in and use a brand new setup token and things should start working.

Sadly this did not work. It's the same outcome as before. There's gotta be something about my actual data on the server that is screwing this up. I just don't know what it is.

@psybers I finally found the issue. My docker network was ipv6 enabled, but at some point I intentionally disabled ipv6 on my router. Funny thing was that I had no idea this was this issue, because there was nothing in the logs to indicate this until I tried manually set the accesstoken in the database. And then the logs were finally able to indicate that it was trying to reach an ipv6 address and failing. So I deleted and recreated my docker network without ipv6 and now it works!

@beatgammit
Copy link

I've set it up and so far, I'm liking it! Here are some thoughts.

I can't seem to move an account from "For budget" to "Off budget." The advice I found is to create a new account and move transactions, but it's not obvious how this works with the sync.

If I add a new account, I need to click through a few times to find it (e.g. add account, link account w/ SimpleFIN, select category, etc). It would be nice to have the bank sync prompt me to add (most likely) or explicitly ignore (very unlikely) accounts, and then remember that setting.

When there's a network, there are a ton of messages popping up all over the screen. Perhaps further errors should be ignored if there's already an error on screen instead of just stacking up.

But honestly, it's been pretty smooth! I set it up a couple weeks ago, and then got around to categorizing my transactions, so I haven't had a lot of experience "living" with the sync, but I haven't had any major issues.

@kjohnsen
Copy link

kjohnsen commented Sep 4, 2024

I got this set up a few days ago; it's working so far mostly, except a few institutions supposedly supported aren't working (annoying since my main checking account and savings accounts are in one of them). The developer responded and will hopefully get the connections fixed soon

@muammar
Copy link

muammar commented Sep 4, 2024

Since last actual budget update, SimpleFIN stopped working for me. Any idea on how to debug this?

@ncsusix
Copy link

ncsusix commented Sep 5, 2024

Is it possible to have a setting to not download pending transactions. I'm having issues with transactions at restaurants that include a tip. Actual will import the initial pending transaction which will not include the tip value. When the transaction does finally post, the value does not get updated in Actual. I have to manually update the transaction to include the tip value.

@Karthik7417
Copy link

Hi,

I just setup actual budget from scratch with actual-server edge docker image. I'm getting the same error that @Towerism posted last month.

1. create a new app in simpleFIN and copy the setup token
2. click "Link bank account with SimpleFIN"
3. enter setup token
4. click "Save and continue"
5. click "Link bank account with SimpleFIN"
6. repeat steps 3-5 endlessly

Also, SimpleFIN shows my token as unclaimed. I'm confused about how to solve.

@shanep2300
Copy link

I had one issue fixed on SimpleFINs side with an account another one I think it’s ActualBudget.

FidelityRewards keeps trying to sync 2 monthly balance payments as payments and not deposits. Also those 2 transactions are from 2 months ago and still appears today even though they already exist. No other bank has this issue. Tried removing and recreating the link from scratch multiple times.

Adjusting the auto transactions to the appropriate deposit amount still brings in the wrong transactions when I do a sync. It’s stuck in a loop. No matter what I do to try and or even those 2 transactions they come back.

@psybers
Copy link
Contributor

psybers commented Sep 14, 2024

@shanep2300 You should use a script like this to verify the data coming from SimpleFIN: https://gist.github.com/psybers/60e7332f93dc59f3ac5f636827921e17

What you describe sounds like bad data coming from SimpleFIN. Actual only adds transactions it gets from that API.

@latetedemelon
Copy link

latetedemelon commented Sep 14, 2024 via email

@shanep2300
Copy link

shanep2300 commented Sep 14, 2024

@shanep2300 You should use a script like this to verify the data coming from SimpleFIN: https://gist.github.com/psybers/60e7332f93dc59f3ac5f636827921e17

What you describe sounds like bad data coming from SimpleFIN. Actual only adds transactions it gets from that API.

Alright so I assume it's bad data. One of the transactions is showing up twice when I ran the script as a positive and negative amount, which the sync keeps trying to add the positive one when it should just be the negative. The other transaction that shows in AB is not showing from the script as it's older but I'm assuming it's the same issue.

This should be rerouted back to simplefin?

@psybers
Copy link
Contributor

psybers commented Sep 14, 2024

@shanep2300 Yes, and give those two transactions from the script when you report it. Copy paste the fun transaction data so they can send it upstream to Mx.

@MatissJanis
Copy link
Member

SimpleFIN has been released as a first-party issues. If there are further issues - please open individual Github Issues.

The feedback thread is now closed.

@MatissJanis MatissJanis unpinned this issue Sep 18, 2024
@actualbudget actualbudget locked as resolved and limited conversation to collaborators Sep 18, 2024
a-gradina pushed a commit to a-gradina/actual that referenced this issue Sep 24, 2024
matt-fidd added a commit that referenced this issue Oct 3, 2024
* marked files for translation

* added release note

* fixed linting warnings

* 🐛 fix account filters being overridden (#3441)

* :electron: Reduce package size  (#3443)

* reduce package size of all packages

* release notes

* Update beforePackHook.ts

* [Maintenance] Cleanup react aria packages and dedupe (#3450)

* Cleanup react aria packages and dedupe

* Release notes

* ♻️ (synced-prefs) moving the prefs from metadata.json to the db (#3423)

* :electron: Restart server silently when adding self signed cert and add some logs (#3431)

* restart server silently on add self signed cert and add some logging

* release notes

* fix name

* updating names to be more specific

* removing setloading

* feedback

* ♻️ (synced-prefs) move budget type to synced prefs (#3427)

* update synced account balance in db if available (#3452)

* 🐛 (synced-prefs) fix bulk-reading not working in import modal (#3460)

* fix: csv import deduplication (#3456)

* ✨ release simplefin as a first-party feature (#3459)

Closes #2272

* Do not allow renaming to an empty category or group name (#3463)

* Do not allow renaming to an emoty category or group name

* Release notes

* [Mobile] Fix #3214 - Pull down to refresh triggering clicks on budget cells (#3374)

* Fix #3214

* Fix rollover indicator

* VRT

* Fix typecheck error

* VRT

* Release notes

* VRT

* Update style

* Fix budgeted

* VRT

* VRT

* Revert VRT

* VRT

* Fix style

* Revert usePreviewTransactions

* Fix error

* Fix reports form submit handlers (#3462)

* Fix form submit handlers

* Release notes

* :electron: Remove some old updater code (#3468)

* remove some old updater code

* remove old updater logic

* CSV import e2e tests (#3467)

* Fix React Aria Button hover styles  (#3453)

* Fiox hover styles and use className instead of inline to prepare for future css migration

* Release notes

* Cleanup

* Update edit rule hover style

* Undoable auto transfer notes + auto notes for cover (#3411)

* Undo auto transfer notes + auto notes for cover

* Release notes

* Fix notes

* Fix notes undo

* Do not show clicked category on transfer or cover menus

* Fix typecheck error

* typecheck

* Fix removeCategoriesFromGroups

* 🐛 (reports) deleting custom report should remove it from the dashboard (#3469)

* Revert "CSV import e2e tests (#3467)" (#3474)

This reverts commit 5e12d40.

* ♻️ (synced-prefs) separate metadata and local prefs out (#3458)

* :electron: Replace deprecated file protocol registration (#3475)

* replace deprecated file handler in electron

* release notes

* types eh

* types

* update sql regexp to default to empty string when field is null (#3480)

* ♻️ rename report/rollover budget to tracking/envelope (#3483)

* 🐛 (import) fix csv import checkboxes not working (#3478)

* Update tooltip and themes with better visibility (#3298)

* Update tooltip and themes with better visibility

* Rename merge request # into release notes

* rename release note

* update VRT

* tweak light theme

* dont put border on autocomplete menus

* update VRT

* tweak popover style

* simplify

* update VRT

* update VRT

---------

Co-authored-by: Dustin Conlon <[email protected]>
Co-authored-by: Dustin Conlon <[email protected]>
Co-authored-by: youngcw <[email protected]>

* fix modals on mobile BudgetTable (#3487)

* Fix privacy filter (#3472)

* Fix privacy filter

* Release notes

* Coderabbit suggestion

* VRT

* VRT

* Revert VRT

* VRT

* VRT

* VRT

* VRT

* Delete VRT

* VRT

* Revert VRT

* 🐛 fix custom reports crashing when opening table (#3484)

* 🧪 (tests) adding custom report e2e tests (#3493)

* ✨ (dashboards) ability to save filters & timeframes on spending widgets (#3432)

* marked files for translation

* Revert ":bug: fix account filters being overridden (#3441)"

This reverts commit 7336bad.

* Revert "Revert ":bug: fix account filters being overridden (#3441)""

This reverts commit 5cbadc4.

* Revert changes due to failed rebase

* removed import of t

* fixed lint warning

* added PayeeTableRow.tsx

* needed changes

* bugfix: pluralization

* variables adjustments

* removed doubled trans

---------

Co-authored-by: Matiss Janis Aboltins <[email protected]>
Co-authored-by: Michael Clark <[email protected]>
Co-authored-by: Joel Jeremy Marquez <[email protected]>
Co-authored-by: Matt Fiddaman <[email protected]>
Co-authored-by: Koen van Staveren <[email protected]>
Co-authored-by: Ryan Bianchi <[email protected]>
Co-authored-by: Robert Dyer <[email protected]>
Co-authored-by: Dustin Conlon <[email protected]>
Co-authored-by: Dustin Conlon <[email protected]>
Co-authored-by: youngcw <[email protected]>
Co-authored-by: Tim <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bank sync Related to automatic bank syncing experimental feature Related to an experimental feature feedback Single feedback thread for bug reports on a new feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.