[Kmymoney-devel] [kmymoney4] [Bug 333498] bulk edit actions results in amount of transaction being zeroed

[Chris]

On 21/04/2014 4:25 AM, Allan wrote:
> On 20/04/14 13:44, Chris wrote:
>> Hi Allan
>>
>> Unfortunately this is not a solution. You should be able to update the
>> amount using the bulk edit feature.
>
> When you say "You should be able to update the amount using the bulk edit 
> feature.", do you mean that it is supposed or stated to, or do you mean 
> "It would be useful if it did"?  My immediate thought the other day was, 
> "Why would anyone want to do that?". With just a quick look, I can't see 
> any relevant code.

That was my first thought too. but I can see the need for editing amounts 
even in multiple edits.

The code inside the "if (category_label) {" is all relevant to editing the 
amount. The code is run regardless of whether it is a new transaction, 
multiple edit or single edit. So it is definitely needed.

silently discarding value changes just because its in multiple edit mode 
will probably have unintended side effects.

>
>> The problem seems to be that the val field is not checked whether it
>> has changed or not. It is cast to a Mymoneymoney object and as it is an
>> empty string that object returns a 0
>
> I would suspect that it is not checked because it is not expected to change,
> but the devs really need to pronounce here.
Yes

>
>> The object probably should have a "NaN" test, it does not appear to have
>> such a test. Failing that the text field should be checked before the
>> MyMoneymoney object is instantiated and used.
>
>> What is confusing is for some reason
>> StdTransactionEditor::slotUpdateCategory tests for the existence of the
>> category label "if (categoryLabel)" and skips updating the value if it
>> exists. It seems that that may have been a kludge fix for some other
>> issue. The fact that the two types of editing, inline and using the
>> form, have two different program paths says to me there are bigger issues.
>>
>
> Again, I'm not an expert, but comparing the transaction form with the 
> register fields, one has an Amount field, and the other has Payment and 
> Deposit, so the processing needs are somewhat different.  My deduction was 
> that testing the Category label was a way of determining  which to use.  
> Possibly the devs can clarify/contradict.

As stated above the same code runs whenever there is an edit (including new 
transaction) so my guess is that test determines whether its an inline edit 
or using the form.  Why there is a difference between the two editing 
methods I don't know

Some advice from the devs certainly would help.

>
>> Lastly when editing multiple transactions if you select a category that
>> has a tax auto split on it, it silently fails to add the tax split. That
>> is pretty crazy. If you rely on this software to do your annual taxes
>> and it silently discards taxes, then you may have problems with your tax
>> office. At the very least it should issue a warning. preferably it
>> should create the split properly. I don't know if I want a stint in jail
>> due to a software bug.
>>
>>
>> Chris
>
> This last paragraph needs dev. input.

Only to say yes we need an alert at the very minimum. It is a major failing 
to silently bypass tax allocations. To get more traction on this I'll submit 
it as a bug.


Chris

>
> Allan
>
>
>> On 17/04/2014 8:38 AM, allan wrote:
>>> https://bugs.kde.org/show_bug.cgi?id=333498
>>>
>>> --- Comment #3 from allan <agander93 at gmail.com> ---
>>> On 16/04/14 13:01, Chris wrote:
>>>> https://bugs.kde.org/show_bug.cgi?id=333498
>>>>
>>>>               Bug ID: 333498
>>>>              Summary: bulk edit actions results in amount of transaction
>>>>                       being zeroed
>>> I have a potential fix for this, which appears to do the necessary,
>>> without any apparent harmful effects.
>>>
>>> In void StdTransactionEditor::slotUpdateCategory(const QString& id),
>>> circa line 1543, there is an updateAmount(val), which now I execute only
>>> if (!isMultiSelection().
>>>
>>> I don't know if there may be a better way/place to do this.
>>>
>>> I notice also, that Buy and Sell activities have a similar problem if a
>>> fee account is entered.
>>>
>>> Allan
>>>
>>
>>
>>
>>
>> _______________________________________________
>> KMyMoney-devel mailing list
>> KMyMoney-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kmymoney-devel
>>
> _______________________________________________
> KMyMoney-devel mailing list
> KMyMoney-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kmymoney-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20140421/29c56dd8/attachment.html>