Almost solved: new hint on account unmapping problem

[Jack]

On 2018.04.19 10:52, Jack wrote:
> On 2018.04.19 03:16, Thomas Baumgart wrote:
>> On Donnerstag, 19. April 2018 00:06:24 CEST Jack wrote:
>>> Since the release of 5.0, there have been several different threads  
>>> about accounts not being able to update (direct-ofx) but still  
>>> appearing mapped (you can unmap the account, but not update it.)
>> >
>>> I just ran into this again with a version compiled from git head  
>>> maybe two weeks ago.  (I'm starting a new compile now.)  My main  
>>> investment account showed this problem.  So - I unmapped and  
>>> remapped, set the download start date, updated the account, fixed  
>>> some transaction details, and saved the file.  I noticed some  
>>> apparently missing transactions, and went to update the account  
>>> again - but it was back in the starting state - no online details  
>>> in the account edit page, but I can unmap and remap.  I did that,  
>>> then immediately saved the file, and it reverted to not being able  
>>> to update the account.
>> >
>>> Does this seem like something in the file/save process is changing  
>>> something so it won't work?  I have not yet identified anything in  
>>> the file that seems wrong, but other accounts at the same broker  
>>> (Merrill Lynch) continue to work fine, so far only this one account  
>>> shows this problem.
>> >
>> > Does this trigger any thoughts as to what might be going on?
>> 
>> I thought, that I have fixed that a while ago on the 5.0 branch:
>> 
>> commit bd6c509f2b2bef5fed962e751d13e14c68190980 (5.0)
>> Author: Thomas Baumgart <thb at net-bembel.de>
>> Date:   Mon Apr 2 10:35:42 2018 +0200
>> 
>>     Keep the OFX importer object name as provider
>> 
>>     Using the new plugin structure there is no need to use a fixed  
>> name     anymore. Use the objectName() instead and things match.
>> 
>>     BUG: 392603
>>     FIXED-IN: 5.0.2
>> 
>> and master as well:
>> 
>> commit 4480920d5d8627384e5cf1a1396644191e732df5
>> Author: Thomas Baumgart <thb at net-bembel.de>
>> Date:   Mon Apr 2 10:39:08 2018 +0200
>> 
>>     Keep the OFX importer object name as provider
>> 
>>     Using the new plugin structure there is no need to use a fixed  
>> name
>>     anymore. Use the objectName() instead and things match.
>> 
>>     BUG: 392603
>> 
>>     (cherry picked from commit  
>> bd6c509f2b2bef5fed962e751d13e14c68190980)
>> 
>> 
>> or do we chase a different one here?
> 
> Of course with fresh compiles, I can no longer reproduce this. :-(   
> Perhaps the last of those commits was after my previous compile.
> 
> On the other hand, once KMM managed to correctly (?) import all  
> pending transactions in the problem account, I now have two more  
> months with the problem interest transactions I've mentioned  
> elsewhere.  I got January to work OK by downloading the dates other  
> than the one with those interest transactions, and I suppose I'll  
> have to do that for Feb and March also.   (I know the issue is at  
> least partly due to how Merrill Lynch creates those transactions, but  
> once imported, they claim the category used is a closed account and  
> so I can't edit or delete the transaction.  That category does appear  
> still open, but we can keep that discussion in the other thread.)

It seems I spoke too soon.  With new versions (I've tried both 5.0 and  
master) I started seeing the problem again.  However, I think I finally  
found the culprit, although still not the cause.  All other mapped  
accounts have provider="ofximporter" but the problem account has  
provider="OFX Importer" - even if it is case insensitive, there is an  
extra space in the middle.  Manually fixing this in the file and  
reopening in KMM, and I can update.

However, after a new import, I tried to match one imported transaction  
with a manually entered on, and got "Unable to accept transaction:  
Invalid transaction id 'T000000000000015347', thrown in  
/usr/portage/tmpdir/portage/app-office/kmymoney-9999/work/kmymoney-9999/kmymoney/mymoney/storage/mymoneystoragemgr.cpp:915".   
Oddly, the match seemed to work OK, and doing a find on that  
transaction shows it is the transaction just earlier in time to the  
manually entered one I just merged.  This seems somehow similar to the  
crash I get on closing a file after importing one of those transactions  
which ends with a "closed" category complaint.  It seems to not be able  
to find an account or transaction which does exist.  I'm wondering if  
there might be a stray, non-printing character in the ID, or if there  
might be some encoding or character mapping issue?  I know I'm grabbing  
at straws here.

As always, troubleshooting suggestions are welcome.

Jack