[Inquiry]GNUCash SoC - Implementing Undo

Tue Mar 27 20:59:28 EDT 2007

In the scenario given, It would not be possible to undo from account B as
the state of the transaction would've been modified elsewhere.

I think it is the lesser of all evils, as a global list may involved undoing
a transaction that isn't visible or switching to a different account view.
If I were to Undo (3) I would need to show Account C or D by jumping to
them, or I could just undo the change quietly. Both seem less than friendly
to me.

A transaction based approach would cause issues with deletes, and bobbled
operations where you cannot find the transaction you just modified usually
because you don't know which one it is.

On 3/27/07, Peter Selinger <selinger at mathstat.dal.ca> wrote:

> akintayo holder wrote:
> >
> > Hi,
> >   I agree with your points, except for the single GList. I think Undo
> needs
> > to be local in context. In other words if I Undo from a given register,
> it
> > should only undo the operations made from that view even if they do not
> just
> > impact this view. So it must be possible to associate an undo with a
> > view/account.
>
> I don't think the idea of a view-local undo will work. Suppose you
> have a transaction as follows:
>
> Account A: +100
> Account B: -100
>
> (1) Then you change it, from the Account B view, to:
>
> Account C: +100
> Account B: -100
>
> (2) Then you change it, from the Account C view, to:
>
> Account C: +100
> Account D: -100
>
> (3) Then you change it, from the Account C view, to:
>
> Account C: +200
> Account D: -200
>
> Now suppose you hit "undo" in account B. What exactly do you expect to
> happen? Should edits (1)-(3) be undone at once? Or only edit (1),
> without undoing (2) and (3)? Or none of them? What if you made some
> other changes in account C after (2) and (3)? Should they be undone as
> well?
>
> I agree with Derek that operations should be undone in the order in
> which they were performed, i.e., at the book level, not the account
> level.
>
> Alternatively, if a local undo operation is absolutely necessary, then
> it should be associated with transactions, not with accounts (i.e.,
> undo the last change in the highlighted transaction).
>
> -- Peter
>
>
> > I would prefer to maintain list for each account, rather than search a
> > global list for undos associated with the type/view. I do see a problem
> with
> > this approach, but the headache due to multiple lists seems equivalent
> to
> > the managing a global list. In the global case you would need to be
> aware of
> > the view/account and maintain positions in the list for each of these,
> and
> > similar complexity when updating the lists etc.
> >
> > With Import I would assign it to the containing Account Hierarchy. I
> would
> > be tempted to do so with most dialogs like Price Editor and Security
> Editor.
> > Reports would be treated to its own GList, as if it were an account.
> >
> > Akintayo
> >
> >
> > On 3/25/07, Derek Atkins <warlord at mit.edu> wrote:
> > >
> > > Um, but which account do you associate it with?
> > > When you Undo don't you want to undo from the UI, not on a per-account
>
> > > basis?
> > > And what about something like a QIF Import, which really should be an
> > > atomic do/undo object?  Where would you store that info?
> > >
> > > Keep in mind that Undo does NOT need to be persistent.  As soon as
> > > you quit the application it's perfectly reasonable to lose your
> ability
> > > to undo.  Think about the "emacs" undo operations as a decent model.
> > > Or Open Office.
> > >
> > > Personally I STILL think it's better to just have a GList in the
> > > session and base your Undo list on that.  I think putting it into the
> > > account would just cause much more confusion and probably not solve
> > > all the problems.
> > >
> > > Keep in mind that users want to "undo" changes that aren't necessarily
> > > transaction input!  You might want to undo, e.g., a PriceDB entry, or
> > > a new Customer, or an Invoice entry, or...  Lots of things that don't
> > > touch Accounts.
> > >
> > > Just something to think about.  Getting the architecture right is
> > > important to success.
> > >
> > > -derek
> > >
> > > "akintayo holder" <blakdogg at gmail.com> writes:
> > >
> > > > 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
> > > >>
> > > > _______________________________________________
> > > > 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
> > >
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
>