> On Jan. 2, 2014, 12:19 a.m., Allan Anderson wrote:
> > I've noticed a potential problem.  When making a multi-edit, the memo field 
> > appears cleared.  If any other edit is made, and the edit is entered, the 
> > original memos are cleared too, which is undesirable.
> > So, what I've done is remove the initial clearing of the memo fields, so 
> > their original content is maintained.  As it happens, I made this 
> > suggestion in the review - "As with all editing of multiple items, all 
> > fields appear as blank initially. This has been retained here with multiple 
> > memo editing, but if desired, this could be changed and the field could be 
> > left showing previous content, which could be more intuitive for a user 
> > wanting to have an empty field."
> > I hope this is acceptable.  It also avoids the requirement for a user who 
> > wants an empty memo, to have to enter a character into the empty memo field 
> > in order to delete it to trigger a connect.
> 
> Thomas Baumgart wrote:
>     I am not sure, if that is a good and practical solution. Let's say you 
> have the following scenario:
>     
>     - User selects two transactions containing different memo content
>     - User inadvertently changes the memo field and uses 'Undo' to undo the 
> change
>     - Now he changes another field and enters the transactions
>     
>     What happens to the memo content of the other transaction? Is it changed? 
> It shouldn't. That is why I think leaving the field blank in the first place 
> is the better choice. We can add a "What's this?" or "Tooltip" to the memo 
> edit field which contains the hint that deleting the contents is achieved by 
> adding a single blank.
> 
> Allan Anderson wrote:
>     Let's say I have two transactions, and do a multi-edit on them, to add a 
> memo comment of "Memo".  OK so far.
>     Then I edit transaction A and add to the memo string "MemoB", so A now 
> has "MemoMemoA", then change B to "MemoMemoB".
>     Then I do another multi-edit, and remove the second string.  
> Interestingly, both keep their first string.
>     Next I repeat the above, except I change my mind and do an undo then 
> enter.  So now they are back to "MemoMemoA" and "MemoMemoB".
>     This time,  I repeat the above, but, without entering, I now edit the 
> date jointly, then enter.  The memos still show "MemoMemoA" and "MemoMemoB", 
> so there appears to be no adverse effect.
>     I'll do some more playing about. Assuming nothing seems amiss, am I OK 
> still to Ship?

There is at least one difference between how Investment and Standard 
transactions react in multi-edit mode.  With Investments, it's possible to edit 
the date, whereas that's not possible with Standard transactions.
Assuming it's desirable that they perform in similar fashion, which would you 
prefer?  My initial thought is that it is unlikely that anyone would want to 
edit the dates to be the same on several transactions.


- Allan


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/113427/#review46590
-----------------------------------------------------------


On Oct. 24, 2013, 11:06 p.m., Allan Anderson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/113427/
> -----------------------------------------------------------
> 
> (Updated Oct. 24, 2013, 11:06 p.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 289351
>     http://bugs.kde.org/show_bug.cgi?id=289351
> 
> 
> Repository: kmymoney
> 
> 
> Description
> -------
> 
> There was a previous fix for this problem - Git commit 
> 9485826cfb50816d2df4dac9709b4beb255b8b75 by Cristian One?. Unfortunately, 
> this was inadvertently disabled when BUG:311481 REVIEW:107714 was committed.  
> This is now fixed.
> This review adds the same capability for investment transactions.
> In addition, there have been requests that when clearing the memo field, it 
> should when required be empty rather that containing a blank character.  It 
> is necessary to enter a character in the memo field in order to signal that 
> an edit has occurred, but now that character may then be deleted to leave the 
> field empty, if that is what is required.
> With investment transactions, it is always necessary to enter the security 
> name as well. This requirement could probably be removed, but it is probably 
> sensible to be editing just a single security.
> As with all editing of multiple items, all fields appear as blank initially. 
> This has been retained here with multiple memo editing, but if desired, this 
> could be changed and the field could be left showing previous content, which 
> could be more intuitive for a user wanting to have an empty field.
> 
> 
> Diffs
> -----
> 
>   kmymoney/dialogs/investactivities.h aa4800f 
>   kmymoney/dialogs/investactivities.cpp e4760e5 
>   kmymoney/dialogs/investtransactioneditor.h 20e3819 
>   kmymoney/dialogs/investtransactioneditor.cpp 805bd8d 
>   kmymoney/dialogs/transactioneditor.h f07dafb 
>   kmymoney/dialogs/transactioneditor.cpp 71d94ec 
> 
> Diff: https://git.reviewboard.kde.org/r/113427/diff/
> 
> 
> Testing
> -------
> 
> Numerous groups of investment and checking transactions entered and edited 
> correctly.
> 
> 
> Thanks,
> 
> Allan Anderson
> 
>

_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel

Reply via email to