There's already a cancel button for the first part. There's no undelete, but it wouldn't be to hard to implement: Just make a second set of QofContainers to hold deleted objects until the end of the session and provide a dialog to list them and allow them to be returned to the primary container.
The normal undo-redo stacks common in other programs would be a bit more complex but the technique is well known, it's just really tedious to implement. Where the problem gets quite a bit more interesting (read: complex and difficult with decisions about depth and granularity) is when the undo stack reaches back into already committed transactions. Do you save a copies of each object for every keystroke or treat an edited transaction like a deleted one? How do you handle an import of many transactions, some new and some matched-and-updated? That's just the beginning, GnuCash is complicated. It could easily turn into several years work for a skilled software engineer; definitely not a job for a hacker. Regards, John Ralls > On Jul 26, 2020, at 7:59 PM, Bruce Irving via gnucash-devel > <gnucash-devel@gnucash.org> wrote: > > While I'm not a professional, there is a point about undo that I would like > to see - sooner than later: I start to edit a transaction but, before I > commit it (press enter or move to another transaction). I realize that I > didn't want to do that and would like to cancel my edit, restoring the > transaction to what it was. > > And, I have accidentally deleted a transaction on more than one occasion. It > would be great if I could restore that transaction rather than completely > re-enter it, hoping I remembered what was in it - I don't! > Bruce > Preach the Gospel wherever you go. > If necessary, use words. > > Hi Jean, > > Am 26.07.20 um 19:57 schrieb jean laroche: >> I'm curious about something: >> If you're a GC dev, contributing code to the project, what's the >> feature(s) you'd like to see added to GC? >> I'm only contributing a bit, but I'll offer my 3 top wishes: >> - Undo/(redo) >> - Multi-transaction (bulk) editing >> - Multi-account (bulk) editing > > All three are violations of strict accounting rules. We often talk about > "In the times of ink and paper", not graphite (pencils). Some > governments require the immutabiity of once written records. > > So I see at least a better auditing system as a requirement before your > suggestions. The current logging would need a review. It should cover > all changes, not only simple transactions. ISTR business actions and > structural changes are not recorded. > >> I'm curious specifically about devs because they typically have a >> different perspective on the project than users have. >> Jean > > About the future I almost agree with Johns suggestions. > > Regards > Frank > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
