[kmymoney] [Bug 507416] Crash under 5.2 when opening existing database

[Luke]

https://bugs.kde.org/show_bug.cgi?id=507416

Luke <kde-bug at luke.fastmail.us> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
     Ever confirmed|0                           |1
         Resolution|DUPLICATE                   |---

--- Comment #3 from Luke <kde-bug at luke.fastmail.us> ---
Reopening based upon some side discussions with Thomas indicating this bug is
not a duplicate in retrospect.

I pulled down the current state of the repo (hash
1fa0eef43b997ca207ce5a916397ef3def528545), incidentally, the build-deps
currently are missing libkf5crash-dev for building, but I was able to rebuild
without issue.

Interestingly, whatever changes occurred in the last couple of weeks, or using
the default build flags is preventing the crash on startup, but only
"recent-ish" accounts are visible in the summary view. Navigating to the
"accounts" view shows the accounts and I can open them in the "ledgers" view
without issue. Resizing the window while the "home" view is visible spits out
numerous warnings/errors about unknown account IDs. An example follows of a
pair tied to a specific transaction. 

> MyMoneyFile::countTransactionsWithSpecificReconciliationState: unknown account id "3-account" in transaction "T000000000000002664"
> MyMoneyFile::countTransactionsWithSpecificReconciliationState: unknown account id "66-category" in transaction "T000000000000002664"

>From what I can gather, the problem is tied to data that came from an import I
did years ago from Skrooge to Kmymoney (the missing accounts are all accounts I
opened/made prior to migrating from Skrooge to Kmymoney), and those legacy
transactions having strange metadata. For example, the following is the
contents of the specific transaction referenced above. Clearly the accounts
should not be a mix of an account and a category. 

   <TRANSACTION entrydate="2016-10-30" id="T000000000000002664"
postdate="2016-10-30" memo="" commodity="USD">
   <SPLITS>
    <SPLIT reconcileflag="2" payee="P000237" shares="-897/100" price="1/1"
action="" id="S0001" reconciledate="" memo="" bankid="" number=""
account="3-account" value="-897/100"/>
    <SPLIT reconcileflag="1" payee="P000237" shares="897/100" price="1/1"
action="" id="S0002" reconciledate="" memo="" bankid="" number=""
account="66-category" value="897/100"/>
   </SPLITS>
  </TRANSACTION>

I think the bug is likely caused by all of these legacy transactions that are
internally stored as a split. I've confirmed the accounts being complained
about are all correctly in the XML, as are the categories incorrectly placed
into the account field. The malformed splits are so old that Kmymoney isn't
showing them in the ledgers. There are some entries that are recent, but only
produce one complaint/warning in the console. Inspecting those indicates
they're likely representing a transfer between a modern and imported account,
and the warning is about the legacy account.

This might simply be Kmymoney having changed some bit of logic tied to the
structure of account IDs and categories in a way that was not historically a
problem, and imported accounts violating these assumptions.

-- 
You are receiving this mail because:
You are the assignee for the bug.