After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 333849 - Since Last Run druid changes data before Apply
Since Last Run druid changes data before Apply
Status: VERIFIED OBSOLETE
Product: GnuCash
Classification: Other
Component: Scheduled Transactions
git-master
Other Linux
: Normal normal
: ---
Assigned To: Josh Sled
Josh Sled
Depends on:
Blocks:
 
 
Reported: 2006-03-08 04:41 UTC by Tim Wunder
Modified: 2018-06-29 20:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Tim Wunder 2006-03-08 04:41:32 UTC 
The Since Last Run dialog/druid changes account data prior to the user pressing Apply and shouldn't. 

From IRC discussion:
[11:30:11 pm] <hampton> The standard expected behavior for druids is that you can cancel at any time before clicking apply and your data will not be modified.  Period.  This druid modifies the data and puts it back which, while it sorta works, isn't the same thing.
Comment 1 Christian Stimming 2006-03-08 09:02:30 UTC 
Which data is it that is being changed prematurely?
Comment 2 Tim Wunder 2006-03-08 12:01:32 UTC 
All of it. All the transaction data is written to the accounts. If you're in the middle of the druid, you can open one of the accounts and the transaction(s) is(are) there. If you cancel out of the druid/dialog, the data written to the accounts is removed. 

If I understood hampton correctly, the druid shouldn't write to the accounts until the user presses Apply. Cancel should simply cancel the dialog, not have to undo everything that was done.  

FWIW, I think this is definately a post 2.0 bug.
Comment 3 Josh Sled 2006-03-12 02:19:12 UTC 
This is all to support created-transaction review and SX obsoleting.  We can't really determine the latter until we've run through the SXes, and -- more importantly -- we can't really display a list of transactions unless we actually create them ... unless we were to build up an entire parallel fake account tree and build the transactions against it, then have the register display those, and re-parent them afterwards.

I think the fix here is to pare down the SLR druid, removing both created-txn review and the obsolete handling.  Less/simpler code and no UI weirdness.  This might happen in 2.0.
Comment 4 Josh Sled 2007-01-20 22:56:33 UTC 
Obsolete on trunk, post-15399 (sx-cleanup branch merge).  Didn't happen for 2.0, but 2.2.
Comment 5 John Ralls 2018-06-29 20:59:10 UTC 
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=333849. Please update any external references or bookmarks.