| Summary: | Accidentally frozen transaction cannot be deleted | ||
|---|---|---|---|
| Product: | [Applications] kmymoney | Reporter: | piedro <piedro.kulman> |
| Component: | general | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | jvapr27, p.r.worrall, piedro.kulman |
| Priority: | NOR | ||
| Version First Reported In: | 5.2.1 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
piedro
2026-02-01 18:21:37 UTC
Minor point: please do not use "latest" as a version, it is important to specify the actual version. This is important for folks referring back to this bug in the future, when the latest versions will be very different from those at the time the bug was filed. Thanks.
You are correct - frozen is frozen, and there is no way within the program to reverse this. You have two options at this point. One is to revert to your most recent backup (you do make backups, no?) The other is to manually edit the data file. (make an extra backup) In the program, you can use "Show transaction details" to find the transaction ID ("T" followed by a long number) and then search for that in the file. i believe (it's been a long time seince I've actually looked) the "Frozen" state is stored either as the value of an attribute or as a key/value pair, but it should be obvious. You can look at the previous or next transaction in the file to see the format for an unmarked, cleared, or reconciled transaction to match.
I think (but need to confirm) that there is already a wishlist bug to allow reversing/altering a "frozen" transaction to another state.
I wonder if the freeze transaction button prompts the user with a warning. If not, it may be wise to implement such a thing. The user makes it sound as if it doesn't and it simply marks it as frozen. I have not seen this feature myself but I can see it being useful for those that need to "close" their books no longer allowing transactions to change. This is a more common practice among business accounting. Still, I guess someone had a use case for it here. (In reply to Jack from comment #1) I'm not certain (take a backup before editing the file by hand), but I think you need to look at the SPLIT elements under the transaction. There is a reconcileflag attribute which I think is set to "3" for frozen. Other legal values are "0" for Not Reconciled, "1" for Cleared and "2" for Reconciled. Yes, you are correct - the status of a "transaction" is really the status of a transaction within an account - which is what each split actually represents. As for warning the user before actually freezing a transaction - that is clearly one of the options which should eventually get implemented. First, thank you all your attention! I wasn't used to bug reports getting responses so quickly... really appreciated! Also: I am sorry about the version numbers - "latest" is obviously not useful, won't do it again. Yes, I make backups - though for a program like kmymoney I think they are not that useful. Unless you basically save after every edited transaction... I use kmymoney in bursts of long hour sessions, going back to backup before the last session is really not feasible. But now I learned that there are hidden backups in the folder where the latest "*.kmy" file is saved. They seem to be created automatically - I love it. Rename the one from 5 minutes ago after messing up and, voila!, ready to go! Sadly in my case the two frozen transaction have been created some time ago without me noticing. Yes, in edit mode there is the drop down with these attributes. And here's the thing: Accidentally hovering the mouse pointer over the drop down for a brief moment while the mouse wheel is moving a tiny bit... That's enough to switch to a random attribute without even recognizing. Just close the editor mode and you already froze yourself out of the transaction. This happened to me quite a few times - most of the times a caught the setting before closing the transaction editor. So, yes, @jesse... There is no button nor warning. And I'd really like the idea of any kind of safe guard. It could also be just an opt-in setting that explicitly allows for the choice of "frozen" for this session. Maybe it's just me, but a password secured login to "unfreeze" mode to allow a user to at least unfreeze their own files. Or vice versa: if they decide to want to freeze something they might have to go into the settings page to allow "hardcore book keeping", then freeze some transactions and lock this feature again. There is many ways, depending on the intended purpose... which I don't fully get tbh. A warning that something irreversible is going to happen, if you proceed - that should be the minimum, imho. Thanks, @jack, for the instruction about the way to fiddle with the database. I think I will have to try that route next weekend. \_OO_/ Cheers, p. |