[Inquiry]GNUCash SoC - Implementing Undo

[akintayo holder]

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 <warlord at mit.edu> 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" <blakdogg at gmail.com> 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 <warlord at mit.edu> wrote:
> >>
> >> Ariel <asgnucash at dsgml.com> 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
> >>       warlord at MIT.EDU                        PGP key available
> >>
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at 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
>       warlord at MIT.EDU                        PGP key available
>