[Inquiry]GNUCash SoC - Implementing Undo
Ariel
asgnucash at dsgml.com
Tue Mar 27 21:43:24 EDT 2007
On Tue, 27 Mar 2007, akintayo holder wrote:
> 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.
I think you are thinking too much like an editor.
Undo transactions are recorded in the log (in order to make multi user
gnucash work). When you undo a transaction it's a visible and recorded
change, not just a simple 'change the entry directly'.
I suggest you create a dialog which shows the before and after view.
It would have two panes: on top a list of all the transactions affected as
they exist now, and on bottom what they will look like after.
For things like undo an import, the top pane will have a long list of
transactions, and the bottom one will be empty.
Or perhaps, since you never delete/add transactions and modify them
simultaneously (I think?), have three views: a changed, an added, and a
deleted, transaction undo screen.
Personally, I would like to be able to browse back and forth through the
undos, and I think this will work well: on the left a list of possible
undo's, on the right the screen I mentioned above showing what the undo
changes.
Let the user cherry pick which transaction to undo - it doesn't have to
be in strict reverse order.
The usual check, which was designed for multi-user undo would still apply:
you can not undo a transaction if it's current state does not match it's
old. Transactions like that would still be listed, but marked in some
fashion - I guess by showing all three version: current, old, and undo.
-Ariel
> 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
>>>
>>
>>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
More information about the gnucash-devel
mailing list