[Kmymoney-devel] Review Request 113427: Editing mulitple transactions - cannot change Memo field

[Thomas Baumgart]

Hi,

On Thursday 02 January 2014 20:59:02 Allan Anderson wrote:

> > 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.

That might not be the case for automatically imported transactions (as they 
usually carry the correct date) but could be required for manually entered 
ones. I would not mind if it is possible. Staying consistent across account 
types would be a goal. So if it is possible in investment accounts, why should 
we block it in others?

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
Intelligence is the ability to avoid doing
work, yet getting the work done.
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20140103/f4dda45f/attachment.sig>