cone
cone copied to clipboard
bradyt
Deleting a Transaction
It would be handy to delete a transaction from the file. This would allow to correct mistakes made while entering a transaction.
Good idea, but the perceived difficulty does not keep it in line with short term goals.
Suppose for a moment that the home page is not simply showing contents of file, but is a scrollable list of cards each showing a summary of transactions (probably sorted by descending date).
There are three related approaches here, in my opinion:
1, User selects transaction, and deletes it. 2. User selects transaction, and edits it as a text field in app. 3. User presses some button to open file in their favorite text editing app.
Option 1 requires my app to be very well written. It's not clear yet to me how this would work. I'm starting to write a parser, it's possible the parser framework I'm using (dart-petitparser) has some way of knowing the position of the item being parsed, so even you might be able to edit a particular field of the transaction. But that won't be in my initial attempt at getting the parser to work.
Option 2 still requires good coding, even if I open the entire file up in a text editing field. The latter seems very inelegant, and would at least require that cone is checking something like a last-modified-date before trying to write. This places more responsibility on cone for understanding how to properly deal with files. So we can't accelerate this feature. Further, if we are somehow only editing a single transaction, we have the same issues as above as far as knowing where in the file this transaction is to be read from/ written to.
Option 3 would require research. I think it is dependent on which framework we use to access the file (currently using Storage Access Framework and ACTION_OPEN_DOCUMENT), which could change, making this possibly a moving target. Then assuming a single method of file access, we have to consider how we open the file in the external editor, and what UI process the user has to complete in order for edits to happen. If Storage Access Framework is newer, then I don't know that I've ever interacted with this sort of editing handling in Android, and I have no guarantees that the process will be intuitive for users, or anyways that I could even tell them what they have to press to make everything finish properly.
In summary, I think this is not a good issue for me to personally prioritize right now, but if anyone has done research in these tasks, I would greatly appreciate the info.
Similar feature request here: https://github.com/simonmichael/hledger/issues/328.
I would like to have an option to edit transaction, to fix an error. Please, add DELETE and EDIT.
In bookkeeping of old, as I heard, you don't delete transactions. You write a new transaction to reverse the previous one and then write the correct transaction. This app seems to keep the spirit of it, even though deleting and editing is useful :3 but I don't oppose editing lol
@kisik21 Bookkeepers of yesteryear didn't have the advantage of storing all their transactions in git, which is itself a ledger of sorts recording history of changes to transactions. :man_shrugging:
@kisik21 Users can start to approximate the idea that edit/delete could be append only, in a new "copy" feature, described at https://github.com/bradyt/cone/issues/64. I feel this a good initial compromise, as it doesn't introduce any new state, need for an undo, history, or concern for how arbitrary edits work, versus append only. (If I was happier about adding state to my app, I could store the history of deletions for user to copy from. But I'd like to avoid adding more state for now. I'm currently headed in the opposite direction. Soon the formatting options in settings page will be removed.)
Extending the copy feature to behave as you describe, with something approximating the negation of postings, is not a priority yet, it's not obvious how to do that as easily as copy works. (For example, I'd have to parse and negate quantities, like 7 ==> -7, -7 ==> 7.) But for now, users might experiment with just editing the copied value.
The copy feature can approximate a quick edit. You could just add a second version with the more accurate picture, and have a mental note to remove the previous "draft" when you are at an editor.
You could also try the negation for edits. Thought tedious, it might be conceptually interesting, and I will illustrate with an example:
Let's say you're all set to buy a towel, with 5 GBP cash. You quickly enter it into your ledger and begin to complete payment. Then, the retailer informs you that it's actually 7 GBP. You realize you haven't got 5 GBP cash, so you pay with a check, and walk away with the towel. You have a moment to sit down, so you try to fix the ledger for this. Below is a possible initial entry, and a second correcting entry that could be completed pretty easily with the the copy feature. So here, we also decided to put the money in expenses:towel, rather than expenses:misc.
1970-01-01 example
expenses:misc 5 GBP
assets:cash
1970-01-01 example edit
expenses:misc -5 GBP
assets:cash 5 GBP
expenses:towels 7 GBP
assets:checking
You would have the correct balances, and you could consider it a note to edit the transactions when you are at your editor and VCS.
@alerque I wish so much my backend was a VCS, instead of my awful plugin for read/append to file.
@bradyt yes yes yes that is exactly what I meant! And once you're at your PC you can edit the file easily and commit the changes, right?
Can we extend the copy feature from #64 to provide an option to 'revert' the transaction a la git? So after tapping an entry, I get two options, copy and delete. Delete option simply copies the entry but reverses polarity on amounts and shows it in 'Add Transaction' page for quick look before saving. It'll keep the append-only way as you prefer and be a better UX than used having to add signs manually.
