Information pane shows filtered transactions but allows editing

[buchen]

This pull request includes and then extends #5025.

"Derived" transactions are now marked with a little calculator. For example, if there is a cash transfer from account A to B, but only account B is included in the filter, then this transfer is converted into a "derived" deposit.

Derived transactions cannot be edited - neither in-place in the table nor with the dialogs. All other options should work, e.g. create a new transaction for the given account, etc.

@mierin12 I would appreciate if you could help testing this change. Particularly that the all editing functions work. And test if no "derived" transaction leak into the actual model.

[mierin12]

Hello, sorry for the long delay, I will try to look into it this week end.

[mierin12]

I am testing it.
It seems to me that there are false positive : sometimes the transactions are marked as a uneditable derived transaction, while it should not be given the filter. If I am using filter containing every accounts, I still see uneditable derived transactions. I am trying to see why.

I think to have the Edit/Duplicate action greyed is great. I am not sure however that the new icon is immediately clear. Maybe a new text on the context menu, above or below the grey edit/duplicate explaining : "this transaction impacts accounts not available in the current filter, it can not be edited under this filter selection." Or as a tooltip. It feels a little bit strange to see an icon on the transactions to be honest.

I notice also that the custom logo of account is lost when filtering :

[mierin12]

For the logo, I think I found a way to fix, with unwrap().getOwner(). The issue was actually from my initial commit with only the inject.

I am still looking into the rest.

I am wondering, should the internally derived transaction always be shown in the transaction lists ?
Couldn't the original transactions always/almost always be shown in the filtered transaction list ?

PP needs the internally derived transaction for the internal calculation when a filter selection happens, but when it is only for visual listing is there still this need ?
Maybe the answer is different for the different derived transactions, I am seeing :

• Purchase/Sale can become Deliveries
• Security transfer can become Deliveries
• Cash transfer can become Withdrawal/Deposit
  In Performance Calculation
• Taxe can become Removal in case of BeforeTaxe

Example :
Security A is purchased is Sec Account AA and Sec Account BB. I want to see the purchases made in AA.
I filter to AA. Now, the purchases from BB are removed, but if I only selected AA, its purchases are converted to Deliveries. Is it what the user is expecting to see ? Would there be a problem to still show the original and editable Purchases ?

[buchen]

For the logo, I think I found a way to fix, with unwrap().getOwner(). The issue was actually from my initial commit with only the inject.

I see logos also for the "ReadOnlyAccount" which should work because the attributes are copied over into the ReadOnlyAccount (and the logo is an attribute). Can you share the patch? (I am not sure if you can create a pull request against my branch to have it included here)

I am not sure however that the new icon is immediately clear. Maybe a new text on the context menu, above or below the grey edit/duplicate explaining : "this transaction impacts accounts not available in the current filter, it can not be edited under this filter selection."

Agree.

About the logo: I was looking at Iconmonstr where I usually get the icons from. But maybe we use something that relates back to the filter icon?

And, yes, adding a tooltip and a label to the context menu such as "virtual transaction" also makes sense.

sometimes the transactions are marked as a uneditable derived transaction, while it should not be given the filter. If I am using filter containing every accounts, I still see uneditable derived transactions. I am trying to see why.

Can you share an example?

The filtering and the creation of 'derived' transactions happens in the PortfolioClientFilter.

I could think of scenarios that are confusing: say for example, the user is not maintaining the cash account and always has a withdrawal for each dividend transaction. If now only the portfolio is added to the filter, then the dividend transactions are included in the filter (the original) but because the account is not included, there are virtual withdrawals created (which match the actual withdrawals but which are not included).

PP needs the internally derived transaction for the internal calculation when a filter selection happens, but when it is only for visual listing is there still this need ?
[...]
Is it what the user is expecting to see ? Would there be a problem to still show the original and editable Purchases ?

I tend to agree. The 'derived' transactions can be confusing. I am not sure anymore if it improves the user experience.

About showing the "original transactions": We would need at least one more "annotation" to separate whether the original transaction was just converted (purchase -> delivery) or enhanced (add a corresponding removal for the dividend transaction).

Let's go back to square one:

initially, PP was showing all transactions and all transactions as the original. That list was showing the purchase (not the inbound delivery) and the cash transfer (and not the withdrawal). What was it showing "too much" in the case of an applied filter?