Editing transactions inline on the web app is not saving changes until clicking elsewhere (edited)
Hi team,
I noticed starting in mid February, around the time some of the custom report features were rolled out, making an inline edit to a row on the transactions page does not result in a server request to persist the change. Specifically, the PUT to the services.quicken.com/transactions/{transaction_id} doesn't fire until you click somewhere else on the page.
So for example, if I click the "Reviewed" checkbox on an un-reviewed row, it will update the page state (i.e. it will add the green checkmark), but it won't actually send a request to the back end to save that change. As soon as I click anywhere else on the page, the xhr request will go thru and I'll get a toast popup that the transaction was updated.
This isn't just impacting the "Reviewed" checkbox; it's impacting all inline edits. For instance, if I change the transaction category from the inline dropdown, the server request won't go thru unless/until I click on something else on the page.
As a result, the current workflow looks something like this:
- Update transaction 1. (nothing happens)
- Update transaction 2. (the browser sends a PUT to update transaction 1. I get a success toast message)
- Update transaction 3. (the browser sends a PUT to update transaction 2. I get a success toast message)
- Click somewhere else on the page. (the browser sends a PUT to update transaction 3. I get a success toast message).
The workaround above (i.e. step 4) isn't terribly difficult, but it'd be awesome if you could address whatever is preventing these updates from being fired on the initial change.
Thanks,
Mike
Comments
-
Yup, I've been experiencing the same. It's a bit annoying and I hope it'll get fixed!
0 -
Reposting with more details from another thread:
A very real issue is that simply clicking Reviewed, or changing a category or anything inline doesn't force the transaction to save immediately - the save only happens when you make the next mouse click (or probably when pressing tab iirc). Therefore, if you edit a transaction so that it no longer meets the filter criteria that you're using right now on the transaction list, it won't disappear until the next click. This is very easy to replicate using the steps in OP - filter the transaction list by Reviewed = TRUE, click the Reviewed checkmark to review any transaction, and watch. It won't go away until the next mouse click (which might be clicking Reviewed on another transaction, or not). The same thing happens if you filter on a category and change a category so that it no longer meets criteria.
Another way to replicate this issue is to categorize a transaction as a Transfer to a manual account (or to an account where the matching transfer transaction doesn't exist yet). Simplifi will pop up a little question asking if it should create the other side of the transfer manually, but not until the next click. If your next click is on a different transaction then you get a nice little interruption and have to remember which transaction you were thinking about before.
I've been dealing with this issue for a few months and it's quite annoying (though I am getting somewhat used to it which helps). I am pretty sure it started with the New Register / New Transaction List. I hope it can be fixed!
[corrected formatting]
1 -
Hello @EL1234 and @simplify_mn,
I was able to reproduce this issue as well and have reported it to our product team. We will be sure to follow up here with any updates as they work toward a resolution!
Thank you!
SIMPL-33048
-Coach Jon
1 -
Thank you @Coach Jon
1 -
Looks like this might be fixed as of today!?!
Maybe only for marking Reviewed and not for changing categories though…
0 -
Hello @EL1234,
Thanks for letting us know! Glad to hear some aspects are starting to work regarding this feature. It looks like the ticket itself is still being worked on from our side, so they might still be working on a few things regarding this issue. We will continue to keep you updated!
-Coach Jon
0 -
Thanks for the update!
0 -
Hello @EL1234 and @simplify_mn,
I am back with an update from our product team on this issue. It looks like this issue was fixed with the release of Quicken Simplifi Web 6.19.0. I checked from my end and can see that it is working much better now. Be sure to let us know if that is the case for you as well!
Thank you!
-Coach Jon
1 -
Seems like it's still not working with changing a Category, if the filters shouldn't show the transaction anymore. I still need to click or press enter an extra time to get the transaction to be hidden from view.
0 -
Hello @EL1234,
Thank you for letting us know you're still seeing this issue. I was not able to replicate the issue when I tested in my own Quicken Simplifi.
Are you using Version 6.20.0 in the web app? You can check this from the dashboard screen by scrolling all the way to the bottom.
Is this happening with specific categories? Which screen are you using when editing the transactions?
I look forward to your response!
-Coach Kristina
0 -
Hi! I'm on version 6.20.0 and using the Transaction List / Register.
I've tried this with various categories. Here is an example:
Filter to category: Groceries. Change transaction to Shopping category by typing the category and then pressing enter to choose the right one from the list. After doing so, I need to either press enter or tab or click somewhere for it to disappear from view.
Thanks!
0 -
I just tried and experienced the same thing when looking at the transactions for a category in Spending Plan.
0 -
Are you sure that isn't the expected behavior? You find the category, press enter to choose it and then either enter again or tab to let the server know to save the edit to the transaction.
You are using a web app and you are typing into the browser, so it changes on your screen, but to tell the server to update it, you have to then hit enter or tab to another field. It's the same when you edit the transaction in a dialog box, you can change the category field, but that won't update it until you hit the update button to transmit this to the server.
I may be wrong but that is how I see it. And I have certainly been wrong many times. LOL
Steve
Quicken Simplifi (Safari & iOS) Since 2021
Quicken Classic (MacOS) Since 2009
Dollars & $ense (DOS) and MS Money (Windows) 1987-20090 -
The goal per the OP is to not have to press or click again to save the transaction. Or in other words, when the transaction LOOKS updated, it should ACT updated.
0 -
Thank you for clarifying,
I can replicate what you're seeing. When you type it in or use keyboard commands to select the category, an extra keystroke is required to confirm the entry before it is saved. If you use a mouse (or trackpad), then it saves right away. This seems to be intended behavior, but I forwarded it internally to my team for confirmation.
Thank you!
-Coach Kristina
1 -
Thanks @Coach Kristina
I mostly type to find the category I want, so this happens pretty often for me.
1 -
Thanks @Coach Kristina I look forward to knowing definitively whether this is intended behavior.
I can confirm that it works the same in Quicken Classic both on the web and the desktop app. My wife says her statewide student database works the same way (it uses browser access too). My gradebook program worked the same way too.
I wonder if this behavior changed with the update to the Transaction Register because I too kind of remember its being simpler in the earlier iterations of Simplifi. But I have a tendency to forget those kind of things.
At any rate, it is fine with me as is now that I am used to it and it does seems to be rather database standard behavior.
Steve
Quicken Simplifi (Safari & iOS) Since 2021
Quicken Classic (MacOS) Since 2009
Dollars & $ense (DOS) and MS Money (Windows) 1987-20091 -
Hello everyone,
Here is what our product team stated for the fix of this issue:
"In general, we do not want to save every character/change made. Instead, we usually save when the focus of control is lost (indicating the user is done).
However, there are sometimes controls where we should save because of a use case. For example:
- Showing non-reviewed transactions, and you want that to update and disappear when you click the button
- Showing uncategorized, and you change the category, and you want it to disappear
I made the reviewed checkbox case work. The category is harder, so it should be added as a separate, specific bug. The reason it is hard is that you can type, and in that case, we get to the same general problem: we cannot make it save, though it already does if you click enter/tab. The case we could fix and could be put in a new ticket is when you select a category via the mouse."
With that, it sounds like what is still being reported here is already being covered by our product team. Thanks!
-Coach Natalie
1 -
"In general, we do not want to save every character/change made. Instead, we usually save when the focus of control is lost (indicating the user is done).
Right, that makes sense. But after pressing enter to save the category, it would make sense (to me) to save then, as opposed to having to press enter again. Because pressing enter to select indicates that the user is done choosing the category.
I hope they can fix that!
0 -
It sounds like what you're describing in this comment has already been discussed in a different thread, with the recommendation to create an Idea post:
Thanks!
-Coach Natalie
0 -
Done. Posting link for reference:
0 -
I just noticed that selecting a new date for a transaction using the date picker (and the mouse) is also not saving until another click is made. If I change the date on a pending transaction to move it to the future, the cash flow projection graph doesn't update until I click again outside the date field. Also if changing a transaction to the past, it only moves to its new spot in the sorted transaction list after clicking elsewhere.
Shall I start a new thread about this as well?
0 -
Just to clarify what I am seeing…
(1) When I filter for "not reviewed" and click the "reviewed" icon on a transaction in the Transaction Activity list, the icon turns green for an instant and then the transaction does disappear from the list.
(2) When I use the dropdown to change the category of a transaction (with the list sorted on category), the transaction does move to its new correct position in the list.
(3) When I edit the payee (with the list sorted on payee), the transaction does not move to its new correct position in the list unless I click on another control in the same transaction or click anywhere outside that transaction.
(4) When I change the date on a transaction in the date picker (with the list sorted on date), the transaction does not move to its new correct position in the list unless I click on another control in the same transaction or click anywhere outside that transaction.
So…
I thought perhaps the system was not saving changes in a field until it could be certain that the user was through editing that field. That explanation works for (1) & (2), where editing is obviously complete, and for (3), where there is no way to tell until the user leaves the field.
But it doesn't work as well for number (4), where picking a date from the date picker should signal that the editing of that field is complete.
DryHeat
-Quicken Classic (1990-2020), CountAbout (2021-2024), Simplifi (2025-…)0 -
I agree 100% and would like to add to your summary (although a coach may instruct me to start a new thread, which I already did) that typing to find a category and pressing enter to select it should also indicate that the editing of the field is complete.
Also - and I just tested this for fun… when I replicate what you did in #3 (sort by payee and type to edit the payee), and press Enter to either create a new payee or select an existing payee, it also doesn't save until I click somewhere else or press Enter again. In my humble opinion, I think it should.
0 -
It appears that the date picker behavior is by design, since some fields don't update until focus is lost, indicating the user is done. If anyone would like to see changes made to the current design, please request each change by creating an Idea post so other users can vote for it and our product team can review it.
Here is an Idea post that was created yesterday for one particular aspect:
Otherwise, it seems that the bug that was reported here has been fixed. Thank you!
-Coach Natalie
1 -
@Coach Natalie I've seen both of those posts :)
The date thing doesn't affect me that often. It's just something that might make sense to fix. Maybe later I'll spend the time to create yet another thread. Thanks.
1 -
@Coach Natalie — "some fields don't update until focus is lost, indicating the user is done"
Most fields that involve picking a value (as opposed to typing in a value) update immediately.
But not the date picker field ... it only updates after focus is lost. That's confusing.
DryHeat
-Quicken Classic (1990-2020), CountAbout (2021-2024), Simplifi (2025-…)1





