some papercuts from master branch

[Jack]

Just to confirm, Version 5.1.80-b96565589

On 2023.01.08 01:47, Thomas Baumgart via KMyMoney-devel wrote:
> On Samstag, 7. Januar 2023 21:27:16 CET Jack via KMyMoney-devel wrote:
> 
> > On 2023.01.07 08:53, Thomas Baumgart via KMyMoney-devel wrote:
> > [...]
> > >
>>> Not sure about the investment views, but I added some substantial  
>>> changes to the repo today that addresses the balance display issues  
>>> for regular accounts. I still have to take care of the scheduled  
>>> transactions, though.
> > >
>>> Note: selecting the balance column for sorting is suppressed on  
>>> purpose because the balance is calculated and is the result of  
>>> sorting so it cannot be used as its source.
> >
>> There is still something funny.  (Version 5.1.80-b96565589)  The  
>> balance seems good (running to match the displayed order) but in a  
>> checking (brokerage) account, I really can't tell what the sort  
>> order is.  Date is clearly first, status likely next (all are R so I  
>> can't test), but after that, it clearly isn't amount.  Security  
>> would be irrelevant for the brokerage account, but it isn't that  
>> anyway.  I'll be glad to provide a screen shot if it would help.
> 
> A brokerage account should behave like all other accounts: the first  
> sort column is the one selected on the header. In case it is a date,  
> then the following information follows in descending order:
> 
>  - type of entry (tx, schedule, online balance, reconciliation, ...)
I don't understand.  If tx is transfer, then it is a real transaction  
type.   Once a scheduled transaction is entered, does KMM remember  
that's how it was created, or are you talking about future scheduled  
transactions?  I think of online balance and reconciliation as banners  
or dividers, not actual transactions.  I'm I thinking about this  
incorrectly?
>  - status
>  - amount
>  - internal ID
That does make sense, but is not what I'm seeing.  Date is marked as  
first sort order in the header.  All transactions are "R", and in this  
case, stock purchases, so same state and type.  They are clearly not  
sorted by Paymen amount (alpha or numeric) and not by security name  
(which I would not expect in the brokerage account.)  Internal ID is  
likely, although that would reflect the import (OFX) order, which I  
don't remember.  Do we need an option to include the internal  
transaction id either as it's own column or within the memo?  It might  
help in cases like this.
> 
> If the main sorting attribute is a value, then (currently) the  
> default Qt behavior is called (and I don't know what that does). It  
> would be great to have a description on how you think the sorting  
> should behave in the various scenarios. Sample data would be a bonus  
> to have :)
I'll see if I can write down something that makes sense.  One current  
concern, especially knowing (below) that you don't use the config  
sorting specification, is how can the user specify multiple columns for  
sorting?  The above default is fine, but after date, I might want to  
specify amount or payee.  In an Investment account, I might want to  
specify security, number of shares, or value, but all of those after  
date.
> 
> In case you want to take a look at the logic: it is contained in  
> LedgerSortProxyModel::lessThan()
I have not looked yet, but will.
> 
>> I wonder if the "Normal View" tab in the sorting config needs to be  
>> split for Investment and other account types.
> 
> I see. That part is currently not used at all (in master). I left it  
> in so far because I was not sure if it can be removed or if it might  
> become handy at some point.
Especially given differences between investment and other ledgers, I  
think it will end up being useful.

I'm thinking about how to use one of my big investment accounts to  
create a good sample KMY file for testing this.

Jack