Severe bug in reports in master branch

[Thomas Baumgart]

Hi, 

On Mittwoch, 21. Juni 2017 12:49:09 CEST Łukasz Wojniłowicz wrote:

> Hi Cristian,
> 
> Please test latest master branch because I think your issues are fixed.
> 
> Referring to order of transactions in report after transaction modification,
> it was sorting, that was to blame.
> I changed it intentionally while implementing multicurrency totals, but it
> broke your use case, so I returned old sorting.
> First tests show that my use case isn't broken and yours work too, but I
> would expect troubles with multicurrency totals anyways somewhere in
> future.
> 
> During the research, I found a bug (not critical) that transaction IDs
> written to .kmy file aren't being red from the file. Transaction IDs are
> assigned through function during KMM start and stay so till application
> quits. The assignment is according to date. When one changes date, the
> assigned ID won't change till KMM starts anew. The assigned ID is being
> written to .kmy file, but won't be red, because KMM will assign new IDs at
> start.

Well, sort of. For XML based files, this ID is reassigned during file load. 
This is not a bug, but based on a design decision. to keep transaction ids 
small in amount and regain those that were deleted. It should not hurt at all 
to keep the values that are stored in the file. This can be changed in 
MyMoneyXmlContentHandler::endElement() if it helps to solve your issues. One 
thing is critical: you should not base application logic on any of the IDs of 
KMyMoney. At one point, we might change them to something completely different 
which is not in any particular order (GUID). I did not use them as debugging 
and following is much harder and hence used the system as it is today. I know, 
that in some places (ID assignment in general) the current code relies on the 
layout of the IDs (one letter, n digits) but that is only in a very few places 
in the engine code (mymoney subdirectory) and not in the application.

There is an additional piece of information which is used for accessing a 
transaction and sorting per post-date and is obtained via 
MyMoneyTransaction::uniqueSortKey() when the transaction is added to the 
ledger in MyMoneySeqAccessMgr::addTransaction() or modified (since parts of 
the sortkey may change). When loading from file, the creation of that key 
happens in MyMoneyXmlContentHandler::endElement() where the transaction 
loaded. If a transaction does not have an id (it is empty) it is part of a 
schedule and the re-assignment won't happen.

This is sort key is used during the lifetime of the application and not stored 
on file.

So in fact, you have the following indirection:

  m_transactionKeys[transactionid] = sortkey;
  m_transactionList[sortkey] = transaction

This way, iterating over m_transactionList is always in post-date order as the 
sortkey is based on MyMoneyTransaction::postDate()  (see 
MyMoneyTransaction::uniqueSortKey()).

> That was the reason why your reports showed correctly after restart.

I am not sure if I completely understand what your multi currency report 
problem has to do with transaction IDs.

-- 

Regards

Thomas Baumgart

https://www.telegram.org/ Telegram, the better whats app
-------------------------------------------------------------
"I know, a 'real Linux geek' doesn't walk around the wall: He bangs
his head against it until it tumbles down!" -- wobo on FLUG ml
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 208 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20170624/e0ce6c69/attachment.sig>