Bug: Transaction is Committed instead of Rollback'ed

[Derek Atkins]

Actually, I think I did just figure out the "right" way of doing this.
Split out the force-change code into a second function,
xaccTransDoRollback().  Then have xaccTransRollback() see if the
backend has a rollback function; if so, just call that; if not, just
call xaccTransDoRollback().  Then the backend can disable itself and
then call the DoRollback() function to modify the engine without
causing undue commit_edit calls.

This does put the onus of correcting the engine transaction on the
backend, but I think that's fine.  Currently none of the backends
(except mine) even support the rollback method.

Dave, would you like to work on this or would you like me to do it and
just submit patches along with everything else?

-derek

Derek Atkins <warlord@MIT.EDU> writes:

>   * Open an account
>   * Start to edit a transaction
>   * when the popup asks "The current transaction has been changed.
>     Would you like to record it?" hit "No"
> 
> At this point the transaction is still committed (although without the
> changes).  The account is _not_ Rolledback, which is what I would
> expect to happen.
> 
> -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@MIT.EDU                        PGP key available
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/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@MIT.EDU                        PGP key available