[GNC] Pending Edit Behavior in GnuCash

[Adrien Monteleone]

It appears this bug has already been filed: https://bugs.gnucash.org/show_bug.cgi?id=797249

(at least with respect to the inconsistent behavior based on method used. Not blowing up the currently edited transaction is considered a major behavior change, personally I’d prefer the warning appear and be given the option to proceed without deleting the anchor split, or deleting the entire transaction, not just having it vaporize on me.)

Regards,
Adrien

> On Jun 5, 2019, at 5:04 PM, Adrien Monteleone <adrien.monteleone at lusfiber.net> wrote:
> 
> Update on the bug.
> 
> I just tested this under the following circumstance:
> 
> 1. I started entering a transaction with a description that produced an auto-fill of several splits.
> 2. The auto-fill contained 2 splits anchoring to the current register.
> 3. Attempting to right-click and ‘delete split’, using the toolbar button, or using the Transaction > Delete Split menu entry on the 1st anchoring split fired the warning and told me I *cannot* delete this split. My only choice was to accept this, leave the split in place and proceed.
> 4. Attempting to delete the second anchoring split, by either means, was successful, without warning, and without blowing up the transaction, because there was a previous anchoring split still tying it to the current register - results as expected.
> 
> I also tested a fresh transaction with a new description and deleted the anchor split. It erased the transaction completely. Perhaps it should either still fire the warning, or at least leave you editing the transaction without deleting date/num/description/notes, et cetera until you hit Enter to commit.
> 
> Finally, I tested entering another split into a fresh transaction, without putting any memo or amount on the anchoring split. When I tried to delete the anchoring split, I received the warning and was not allowed to delete it.
> 
> So it seems the last of the inconsistent behavior is when entering a fresh transaction and trying to delete the anchor split before entering other splits. I’ll file a bug on this shortly.
> 
> Regards,
> Adrien
> 
>> On Jun 5, 2019, at 4:51 PM, Adrien Monteleone <adrien.monteleone at lusfiber.net> wrote:
>> 
>> 
>> 
>>> On Jun 5, 2019, at 3:06 PM, David Carlson <david.carlson.417 at gmail.com> wrote:
>>> 
>>> I might as well get this debate started now.  Another thread has started a
>>> discussion about unsplitting transactions, pointing out that there is an
>>> inconsistency between using the various  Transaction > [edit] Split keys
>>> and the conventional keystroke editing method using the Tab key to navigate
>>> around a transaction.
>>> I think there should be a warning for any editing action that deletes a
>>> split line, including tabbing off the anchor line.  Obviously, edits to
>>> correct account assignment errors must be allowed and not be overly
>>> encumbered by unnecessary warnings.
>>> 
>> 
>> David,
>> 
>> As I recently (a few minutes ago) noted in that other thread, this is allegedly fixed as of 3.4. (https://bugs.gnucash.org/show_bug.cgi?id=796978) Perhaps the commit didn’t work as expected. I’m getting ready to test it.
>> 
>> 
>>> GnuCash, at least in the 2.6.xx series usually prohibits leaving a
>>> transaction that contains pending edits without using the Enter key to
>>> commit the edits, but it has some exceptions which set up some difficult
>>> situations when finally trying to do a manual File > Save.  At that point
>>> it asks if you want to save edits in some register view which may even be
>>> accidental edits or keystrokes that would delete desired data.
>>> 
>>> The most common action (for me) that sets this up is to start an edit in
>>> some register then navigate to another register without first saving the
>>> pending edit.  This easily happens if the user is reviewing results from
>>> the Since Last Run assistant especially if a cat crosses the keyboard.
>> 
>> Using Sqlite backend, of course I get instant saves so I don’t see this issue anymore, but that sort of ambiguous ’save edits’ question is disconcerting if you are pretty sure you’ve committed all transactions, and now you’re being told you haven’t.
>> 
>>> 
>>> I can see the reasoning that often users may need to view other registers
>>> to compare the transaction currently being edited to something else, so I
>>> do not want to prevent that.  I would propose that the tabs containing
>>> pending edits flash in some way to catch the user's attention so he can
>>> find his way back to see if it was cat-tracks or a real pending edit.
>> 
>> Interesting idea. Though this might interfere with the custom tab colors, I like the idea of some visual indicator that something has been edited and needs attention. (perhaps a bold or italic typeface change?) Flashing however I would not be in favor of.
>> 
>>> 
>>> There are also a couple of cases where attempting to cancel a pending edit
>>> does not correctly restore the transaction to the previous state which
>>> could be fixed at the same time other pending edit behavior is addressed.
>> 
>> Sounds like a bug.
>>> 
>>> Another situation where pending edit behavior is inconsistent is when
>>> editing scheduled transactions, the Enter key may or may not save the edit,
>>> depending on which field the focus happens to be in.  I think that the
>>> enter key should always save pending edits.
>> 
>> Again, I’d think a bug. I would expect Enter to always commit an edit. (especially since the Help manual says as much, or so I recall last time I read it)
>>> 
>>> Finally, I will throw out a radical suggestion that all edits get their own
>>> new window instead of happening within a certain register view with a
>>> certain "anchor" account which has special behavior compared to other split
>>> lines.  This Edit window would not be tied to any account and would be
>>> obviously not saved as long as it exists.
>>> 
>> This already exists as the ‘General Journal’ (Tools menu) It’s your choice to use it. Though it is not implemented for only the currently edited transactions, but the entirety of your data file.
>> 
>> Regards,
>> Adrien
>> 
>