The reason I like Undo being associated with an account is the simple way in which to enforce context. So an Undo could not impact a hidden account in an unexpected way. Since accounting transactions affect at least two accounts, grouping by account was more of an interface concession.
On 3/23/07, Derek Atkins <[EMAIL PROTECTED]> wrote: > > 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 > > [email protected] > > 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 [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
