I'm not convinced that the Undo feature belongs to an account. There are other (non-account-based) operations that should be undoable, such as changes to the PriceDB, direct Transfer Dialog entries, or even changes made via File -> Import. I think the Undo log should be part of the Book (or maybe Session), and there needs to be a way to group operations together into the atomic undo operations.
The rest of your statement I agree with, that Undo should check that the state is correct before it allows the undo.. Same for Redo. Thanks, -derek "akintayo holder" <[EMAIL PROTECTED]> writes: > Hi, > Its seems that with respect to multi-user transactions and Undo, the first > step would be to enforce this rule; A transaction cannot be Undone if the > state of the record does not match the state after the original transaction > had completed. For example, you can only Undo an account creation if the > account was still empty. > > I would implement the update history as an account associated data structure > which is stored in memory. A local history would allow undos to be performed > by simply traversing the account's list and picking the next change. Anyway, > this approach would mean that updates from other users are not aggregated in > one list. > > Thanks for the comments. > > Akintayo > > > > On 3/21/07, Derek Atkins <[EMAIL PROTECTED]> wrote: >> >> Ariel <[EMAIL PROTECTED]> writes: >> >> > It seems to me that an undo in a multi-user environment should be >> exactly >> > equal to the user deleting (or changing, etc) the transaction manually >> > back to what it was. >> >> As pointed out, this isn't completely true. In a multi-user environment >> another user may have updated the transaction so your "undo" shouldn't >> silently discard their changes. > > > > >> Meaning the log file would first show a 'do' transaction and later would >> > show an 'undo' transaction, rather then the transaction not showing up >> in >> > the log at all. >> >> This is true.. >> >> > It's not exactly how undo on an editor works, but I think it's the right >> > thing for gnucash. One consequence is that if you do something and then >> > undo it, gnucash will ask you to save the file, while in an editor it >> > wouldn't. >> >> Well, in a multi-user environment you're certainly using a DB, so there >> would be no "save". Each Do/Undo would effect a save to the DB. >> >> > -Ariel >> >> -derek >> >> -- >> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >> Member, MIT Student Information Processing Board (SIPB) >> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >> [EMAIL PROTECTED] PGP key available >> > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
