[Inquiry]GNUCash SoC - Implementing Undo

[Derek Atkins]

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