[Inquiry]GNUCash SoC - Implementing Undo

[Ariel]

On Wed, 28 Mar 2007, Derek Atkins wrote:

> Except the transaction log ONLY tracks transactions.  It does NOT track:
>
>  - Accounts (create/modify/delete)
>  - PriceDB (create/modify/delete)
>  - SXes ...
>  - Budgets ...
>  - Business Features [Customers/Vendors/Employees/Invoices/...]
>  - etc.
>
> So saying "just use the transaction log" is really limiting yourself,
> or perhaps ignoring a major part of the problem.

Actually, I'd like to turn this around - why aren't those things written 
to the log? I think they should. If I invoice a customer, and then loose 
data, I'd certainly like to be able to replay that.

If they were written to the log then undo for them would be easy.

> I DO understand the want for locality of operation.  At some level it
> DOES make sense to have "register"-based undo context (note that I'm
> saying "register", not "account" -- I think the General Ledger
> register, or even a Search Result register should have an undo
> locality, but those registers do NOT have an associated Account).

> But I ALSO think that there needs to be an application-wide UNDO
> list, for operations that don't have a locality..  E.g. imports,
> accounts/budget/business object creation, etc.

Because of that, is why I suggested that undo has a window of it's own, 
which is application wide, but still usable no matter what view you have 
open at the moment, since it directly shows you what's going to change, 
and doesn't care/use the view you have open.

I don't think it's possible to make undo local to each view.

> This is clearly a VERY big problem, but how can we scope it to make it
> doable in a summer.  Perhaps each QOF Instance has an undo log and
> there's some way to merge all those logs into some serialized list
> based on the current context?

Yes, exactly.

> But of course you still have to worry about the atomicity.  For example, 
> an import operation will create (or modify -- setting the cleared 
> status) a bunch of accounts and transactions at one time, so if you're 
> in an account register of one of those transactions you shouldn't be 
> able to remove that WHOLE transaction without removing the whole import 
> -- and gnucash should warn you about that somehow.

Right, each operation could consists of multiple changes to transactions 
(and other logged actions). All those changes would be bundled together 
into a cluster for the UI. But internally it's still just a list of 
changes to 'loggable atoms'.

 	-Ariel