[Kmymoney-devel] 4.6.9 Minor Multiple Transaction Editing

[Allan]

On 12/03/14 05:02, Michael Garrison Stuber wrote:
> On 3/11/14 5:00 AM, kmymoney-devel-request at kde.org wrote:
>> Message: 1
>> Date: Tue, 11 Mar 2014 11:11:12 +0000
>> From: Allan <agander93 at gmail.com>
>> To: kmymoney-devel at kde.org
>> Subject: Re: [Kmymoney-devel] 4.6.9 Minor Multiple Transaction Editing
>>     Bugs
>> Message-ID: <531EEF50.9020301 at gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> See interspersed.
>>
>> 4.6.90-xxxxx?
> Version 4.6.90-2a9a43922b
>>> (1)  When multi-selecting transactions, if I select two transactions of
>>> different types, editing is not allowed (okay), BUT if I unselect the
>>> offending transaction, I am still not allowed to edit.  I have to
>>> completely unselect all transactions to be able to edit again.  I
>>> haven't looked at the code to see how it works.  If it's reference
>>> counting, perhaps it doesn't decrement?  If it's a lazy evaluation,
>>> perhaps floating the mouse over the edit button could force a
>>> reevaluation based on the current selected transactions?
>> That's not quite the case.  Once you've deselected the errant one(s) and
>> the remainder are still highlighted, hold down the shift key and click
>> on one of them to give focus.  If you're lucky and choose the right one,
>> you are now able to edit them.  If you're not, that one will get
>> deselected, but CTL-select will reselect it.  I think it's the last one
>> of the batch you selected.  Either way, you definitely don't need to
>> completely unselect all transactions.
>>
> Okay.  That works, but I would suggest that most users will never pick
> up on this subtlety.  I would suggest that the list be reevaluated each
> time it is updated such that deselecting the offending transactions
> solves the problem.  Put another way, you've given me a work around
> (awesome!  thanks!), but I still think it needs updating.
>>> (2)  This wouldn't actually be an issue, except I can't meaningfully
>>> filter / search by transaction type.  (i.e., I can't select all the
>>> "buy" or "sell" transactions).  As a result, if I want to change all my
>>> purchases to come from a different account (for example an equity
>>> account because I'm keeping my investment purchase history, but wiping
>>> out my bank account history), but I have reinvested dividends tucked in,
>>> selecting transactions manually becomes tedious.
>>> (3)  When editing multiple investment transactions, the stock gets wiped
>>> out and needs to be reentered.
>> Yes, that was deliberate, but I can't now remember why I left that.  All
>> fields that may be edited are cleared except the account field (for some
>> reason).  So the stock needs to be edited to enable the Enter button.  I
>> think I may need to revisit this area.
> I have a theory as to why:  the current version allows me to edit
> multiple transactions with different securities as part of a edit. That
> said, while it clears fields like security and interest account if they
> are different, it won't allow me to save them "blank" and leave what was
> there previously intact.  I must update these cleared fields.  Thus if I
> wanted to do a mass memo update (maybe to note a tax consequence related
> to year end dividends for future reference), I couldn't do it across
> transactions.  I would suggest that it should either clear the fields
> and allow things to be save "blank" (retaining previous values), or it
> shouldn't allow the edit in the first place.
>
> Question:  In previous versions of KMM there was a setting to select the
> default entry style for securities (price per share, or price per
> transaction).  While there is still the option to set this on a per
> security basis, I can't find the default setting for KMM.  Is it
> missing?  Am I confused?  (Personally I strongly favor total per
> transaction, but historically KMM has defaulted to price per share.)
>
> Another suggestion:  Currently you can't delete a stock if it still has
> prices associated with it.  I can understand not allowing a stock to be
> deleted if you have transactions associated with it, but the prices?  I
> would suggest prompting the user:  "Historical prices associated with
> this stock.  Deleting this stock will delete all associated prices.
> Proceed?"  And, assuming they confirm, wipe out the historical prices
> and the security.
>
Can I suggest you should raise a wish-list bug report for these last two 
points, so they don't fall by the wayside.

Allan