Feature grouped accounts

[buchen]

Continuation of #4466

(possible) open items:

• double-click editing the names does not mark the client as dirty (potentially no saving). And: does it work with editing the name of the cash or securities account?
• what about the ordering of the accounts within the group?

[mierin12]

Hello @buchen many thanks for the review. I will look into it.
Quickly some notes for later:
I think there is an issue with the TaxonomyView, there is the typo line 119 where SecuritiesPerformanceView.class is used, but even when using TaxonomyView.class.getSimpleName() + "-" + taxonomy.getId() I still have issues. Not super sure, but is creating a TaxonomyModel with a filteredclient ok ? The previous implementation keeps all accounts in the model but put a 0 value on them, is that it ? While now it is completely filtering them ? But then I wonder if by creating a TaxonomyModel with a filteredClient some mismatch happens later on such as in addUnassigned

To trig : filter, quit the filtered taxo view, then go back to it.

Regarding the Named interface : the goal was to make the label/name appear in the Information Pane : a Named adaption is used at some point to print the label. without it :


I think have a Name here is important as not all change of selection is updating the information panes (only a newly selected grouped account is updating the information pane, a sub-account selection does nothing).
In InformationPane.java :

/* package */ void setInput(Object input)
    {
        currentInput = input;

        Named named = Adaptor.adapt(Named.class, input);
        label.setText(named != null ? TextUtil.tooltip(named.getName()) : ""); //$NON-NLS-1$

If it is better to update setInput, it can be modified there instead.

Good catch for the two open points. I will look into it.
Well I think it was even worse than not making the client dirty : even after a save, close and reopen, the name is not remembered 😅 It is saved if the view is changed before saving & closing (as dispose is called).

For the ordering of the accounts : I think the Taxonomy drag & drop way could be reused. There it is possible to drag elements and not just main nodes. I went the easy way and used the drag&drop methods from EditClientFilterDialog which was straightforward instead of taxonomy. Otherwise it is possible to sort by the Value column.

[buchen]

Not super sure, but is creating a TaxonomyModel with a filteredclient ok ?

Yes, you are right. Now I remember. The problem is, that a filtered client may not have all instruments and then it does not work to resolve the assignments. I'll fix that. (We are "on the road" this weekend so it will take a couple days).

Regarding the Named interface : the goal was to make the label/name appear in the Information Pane

Ok, okay, understood. It is unfortunate that the Named (the name) and the Annotated (the note) depend on each other.
What I found immediately confusing is that I can enter a note to the group and then it is gone again. The "revert" is a separate commit so we can remove that one again. I also want to look at the code: maybe it is easy to separate Named and Annotated.

as not all change of selection is updating the information panes (only a newly selected grouped account is updating the information pane, a sub-account selection does nothing).

To be honest, I found that also confusing. Particularly, if I select an account, it does not mean that the group of this account is shown. It could be an arbitrary other one.

Why not show infos for the group, if the group is selected? and the infos for the account, if the account is selected? Then one can easily check for example in the holdings chart where does the position come from.

[mierin12]

What I found immediately confusing is that I can enter a note to the group and then it is gone again. The "revert" is a separate commit so we can remove that one again. I also want to look at the code: maybe it is easy to separate Named and Annotated.

I have started some propositions there : master...mierin12:portfolio:pr-4476-modified
The information pane name can be managed by a workaround without Named.class.
For the undirty client after a name changed, I think the listener associated with StringEditingSupport was not ok. I also updated onModified to include the save of modified filter.
Now, as you said, the named changes only works on the grouped account node and not sub element account because of new StringEditingSupport(ClientFilterMenu.Item.class, "label") I am not sure how to add two different StringEditingSupport ? Or we are back at using the Named.class and then column.getEditingSupport().addListener(this); would work for all elements. But this is bringing back the Note topic indeed.

To be honest, I found that also confusing. Particularly, if I select an account, it does not mean that the group of this account is shown. It could be an arbitrary other one.

Why not show infos for the group, if the group is selected? and the infos for the account, if the account is selected? Then one can easily check for example in the holdings chart where does the position come from.

Yes I was not super satisfied by this either. I will look into it. The challenge is that the different panes are not the same depending on if a Cash Account or a Security Account or a Grouped Account is selected.

[mierin12]

Why not show infos for the group, if the group is selected? and the infos for the account, if the account is selected? Then one can easily check for example in the holdings chart where does the position come from.

Proposition done in https://github.com/mierin12/portfolio/tree/pr-4476-modified
I think it works, with the exception that for Balance Chart, buttons are also created for Account Balance chart, but shouldn't.
A Holding chart for Account is not very useful but it was easier to adapt to it than to hide the pane (I do not see how to do that).

Just thinking aloud: maybe the selection is the "Clientfilter" (not some ClientFilterMenu.Item). And instead of sending a portfolio, we can also "just" send a ClientFilter that only includes this portfolio. That would reduce the many if/else in the panes.

I think it is possible for Holdings and Statement of Assets, but for Balance Chart this seems less trivial. I reused c4347d2 and its needs more info than clientFilter.

[mierin12]

what about the ordering of the accounts within the group?

I have proposed an extension of the drag and drop. To be noted : it has no effect if a column is sorted (such as the Balance column or Note column). Should a drag & drop action reset the sorted state of a column ?
There is still a little bug, I am not able to distinguish if the drop target is in the same Grouped Account as the dragged account. I assumed we want to prevent drag&drop between different Grouped Accounts. It is prevented except for the case where : drop target is a account which is also present in the origin Grouped Account.

In addition, maybe the Name column could be sortable but only for the sub elements, while top level Grouped Account are only movable through the d&d.

[buchen]

I have proposed an extension of the drag and drop. To be noted : it has no effect if a column is sorted (such as the Balance column or Note column). Should a drag & drop action reset the sorted state of a column ?

Good point. I agree. Drag & Drop does not make sense if it then creates no change because the values remain as sorted by the column. Maybe drag & drop for the accounts (cash and portfolio) does not make sense...

What about this behavior:

• The "groups" (= client filter) remain always exactly in the order that the users gives them - regardless of how the "Name" column is sorted. The very same order is used in the drop down menus when selecting a "group/filter".
• The accounts (cash and portfolio) are sorted by the column - either name or balance or note or whatever. And they cannot be dragged and dropped.

[mierin12]

Or there is also the behaviour of the Taxonomy which I think is quite good, it allows both drag and drop and sorting. There, the sort is not a "continuous" sort but a one time action, which therefore does not prevent a future drag & drop.
One difference maybe is that it is ok for Taxonomy to drag & drop between "parent node", while I was thinking that for Grouped Accounts the drag & drop of sub account should only happen within the same Grouped Account, but maybe this too restrictive for no real reason.

[buchen]

while I was thinking that for Grouped Accounts the drag & drop of sub account should only happen within the same Grouped Account, but maybe this too restrictive for no real reason.

Well, in the groups you can have the same account in multiple cash groups. If we allow drag and drop there, you also have to take care of this. For example, if you drop the account in a group where the account is already present, does it just remove the account from the previous group?

If we do drag and drop, then I would say we should split the view. On the left side are the groups, on the right side is a list of all accounts. And one can drag and drop an account from the left side into a group.

Within the group, I do not think we need an order. Or, more precisely, we should just use the order that is given from ordering a particular column. I am not sure I want to apply the taxonomy behavior here. It is custom ordering which is then persisted in the XML. In the taxonomy, the thinking was that uses want a specific order of classifications and want to order securities (I do that often when thinking about rebalancing - my "favorite" of a category is on the top). But a group does not need an order.

I'll have a look at your additional commits later this week.