Bug 338588

Summary: When editing a split the whole line needs to be re-entered rather than just the new amount or memo.
Product: [Applications] kmymoney Reporter: george
Component: generalAssignee: KMyMoney Devel Mailing List <kmymoney-devel>
Status: RESOLVED WORKSFORME    
Severity: minor CC: agander93, onet.cristian
Priority: NOR    
Version: 4.6.6   
Target Milestone: ---   
Platform: RedHat Enterprise Linux   
OS: Linux   
Latest Commit: Version Fixed In:

Description george 2014-08-26 21:09:47 UTC
This is an enhancement request to allow one to edit any given field of a split rather than having to reenter the whole line to change just one field.

In my case the electric and gas provider is the same so I use a split to keep track of each.  Each month I need to edit the amounts to reflect the bill. As it stands I must reenter the catagory and memo as well as the new amount.

Reproducible: Always

Steps to Reproduce:
1. Just edit the splits...
2.
3.
Actual Results:  
To change any field the whole line must be reentered.

Expected Results:  
Click on or Tab to the field to be changed, enter the new value then in the same way modify any other field.
Comment 1 allan 2014-08-26 21:24:24 UTC
This works correctly for me on the development version, both in-line editing and in the transactiom form.
Comment 2 Cristian OneČ› 2014-08-31 08:19:39 UTC
This behavior depends on you "Keep changes when selecting a different transaction/split" setting [1]. If the setting is checked then the entered value will be saved when clicking on another line. Otherwise the entered value will only be saved when the 'Enter' action is triggered (using the action icon or the 'Enter' key).

[1] http://docs.kde.org/stable/en/extragear-office/kmymoney/details.settings.register.html#details.settings.register.dataentry
Comment 3 george 2014-08-31 14:28:21 UTC
This option is/was on.  The behavior I have a problem with is that when I bring up a scheduled split transacton to enter the actual values I can not select just the amount fields, but rather have to select the whole line of the split and then I must enter the catagory to proceed.
Comment 4 Jack 2014-08-31 15:50:52 UTC
I think we need more detailed information about exactly where you are trying to do this.  In the ledger, for an existing transaction, I am able to select a split and edit any of it's fields without having to touch the others.  If this does not work for you, something is certainly wrong.  However you mention scheduled transactions - so it might depend on exactly how you are selecting and opening the transaction for editing.
Comment 5 Thomas Baumgart 2014-08-31 16:13:10 UTC
George, as Allan mentioned this behavior cannot be duplicated using the latest development version. In case you see it in 4.6.6 then consider it as fixed in the next release. If you see this in the current development version, please give us exact details on how to reproduce the false behavior. I do agree, if things work as you describe it must be fixed (but only if it is necessary).
Comment 6 george 2014-08-31 20:33:57 UTC
(In reply to Thomas Baumgart from comment #5)
> George, as Allan mentioned this behavior cannot be duplicated using the
> latest development version. In case you see it in 4.6.6 then consider it as
> fixed in the next release. If you see this in the current development
> version, please give us exact details on how to reproduce the false
> behavior. I do agree, if things work as you describe it must be fixed (but
> only if it is necessary).

Sorry, I had some problems getting the git version to build (wish I knew C++ better).  Anyway, yes the git version is much better.  

Some of the steps are a bit clumsy, but that is true in alot of places.  In this case, if we open to edit, why do I have to double click or rt. click to edit the amount (a single click shoule do)?  Also, if I am entering a scheduled transaction why can't I just edit from there instead of going back and saying I want to edit.  And editing the scheduled transaction from the ledger adds confusion (since I only want to edit the given entry).  If changing all future transactions was only possible from the "scheduled transactions" area the question about saving the current edit for later would disappear.

In any case this issue is resolved in the git version, so marking.