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 ?