While we do allow people to change the width of column in tree views this feature do not work in sao.
Often this is done because some columns are useless for said user but the trick is that this column could be used by another user.
Proposal
I would like to propose the addition of a new attribute to fields specified in tree views.
This optional attribute would specify that this column could be added (or removed) from the interface by the user. Of course it’s up to the developer to decide if some columns are optional or not.
On the server side we would have an object storing by view ID and user the list of the displayed column and their order. The column list will be stored as a JSON list.
When requesting the view the server would send the view definition from the module if the view has not been changed by the user. Otherwise we would send the modified view and the list of the optional columns (so that user can update his view if he wishes to do so). Some validation during the computation of the modified view will need to occur (eg that all the non optional columns are present).
On the client side a button will allow the user to chose the columns he wants to display (with the option to remove the optional ones) and their order.
Currently the system administrador is who decides if the user is allowed to see a colum or not (because he is the one to create the access rules). So I’m wondering if we should them (and not only developers) to customize the optional columns.
Instead of adding the attribute to the python code I think we can add it to the ir.model.field table so the administrator will be able to define if such colum is optional or not.
I thought that since list are ordered we had for free the fact that people can reorder the columns and since some will put the focus on some columns and others on another column I thought they might want to reorder them.
I do not think it is really a matter of focus.
But for me the field already defined in the view should stay at their position and the new field added should be added in the order they were added. If each field is stored in a record than ordering them by id will be enough. But at some point it will be just a behavior of the feature and not really the feature.
I do not agree. For example the company and the warehouse fields may be optional on some setups (due to the usage of a single record of them). So this is something that the system administrator should setup.
Otherwise we end up adding the optional on most of the fields.
The majority of the currently displayed field are required on editable list.
And for non-editable there are only few fields for which it could make sense to not display.
Unless it has a default value which is the case of both fields.
It depends on the usage but the feature talks about adding and removing optional fields and this is something that an admin (without coding) can decide like the user can decide which fields to choose from the list of optionals.
I see no real reason to restrict the feature only to coders but I see this may help to solve hide unused fields
Nobody knows if this work. And I think we should not care about that.
No an admin can not decide if a field is optional. Only someone who knows the code can decide if a field is optional.
We should not care to solve this false issue. There is no good reason to remove field from the form.
To be clear it is never a good idea to let the user edit the interface. He does not have the knowledge to do that correctly. The only reason I think we could consider this feature is because list has a limited number of columns to stay practical. But it can only be right if it is well guarded to prevent any issue.
I think we should rather hear to those issues and extract the problems. Tryton has improved a lot to not show redundant information, but there are still places where one can find.
Currency is at least two times a redundant information. I can not imagine a case where the currency of the untaxed amount and taxes is different from the total. While this specific problem should in the first place rather be solved by improving the original view instead of removing some fields I would consider this a valid point of How to hide unused fields globally?.
We shouldn’t underestimate users;) Why should a user not know if he wants to see or not to see e.g. untaxed and tax columns in the example above?
I thought about it but for me it’s a property of the view and not an intrinsic property of the field.
About the overall issue of making all fields of the view invisible, I agree with @ced. It would allow to break the view too easily : I have seen people turning usual list views into editable list views in their own module. If we let the user decide the visibility of all the fields then this set up would be too easily broken resulting in support requests and so on. So I don’t think it’s a good idea and the people managing the code should handle that.
But it raises the question should the optional attribute on the field be checked? I don’t think so (people can still shoot themselves in the foot if they really want to but we don’t make it easy), that way if you want to make all the fields optional in a view you still do it.
I’m not sure to understand this. Do you mean that all field of the view must be optional by default? Or if optional field on a view are displayed or not by default?
I think that
a field without optional attribute can never be hidden
a field with optional attribute set to 0 can be hidden
a field with optional attribute set to 1 can be made visible
So as all fields have a specific place in the raw view, we do not need any ordering needs. It is just a matter to toggle the existing optional attribute if the field has been registered by the user.
It should take care of the cache on both side.
I’m wondering if it will not be better to always send the same view plus the preferences and let the client modify the view.
Even instead of modifying the view, it should probably just hidden columns and not mark “invisible” field as eager load. This way when the user toggle the “visibility”, the column just have to be made visible and the field eager loaded to trigger the load.
No I mean in the process on the server side to compute the user view ; should we have some validation that the the field that the user chose to not display is originally defined in the view as optional.
I am not sure if it’s something that people would like to do or not. As it does not appear too difficult to do I had this idea but would users reorder the fields? I honestly don’t know.
Yes of course.
Primarily I was thinking that the computation of the view should happen on the server side because that way we don’t read useless fields but using their eagerness could solve it too indeed.
In our experience the users want both hide and reorder fields. Indeed they complaint more about reordering due to they actually can reduce column width (in gtk client).
If the implementation is done on the client side otherwise the cache invalidation issue is still there.
They make the column disappear by setting their width to 0, is that so?
So obviously the missing feature from their point of view is the ordering because somehow they already make some columns optional.
that is, they shrink columns to the minimum width being carefull to not set width to 0 because then is difficult to recover them . It is still a trick …
I suspect your worries are mainly with the editable views. I can not see so issues to hide/show a field on a non editable view if the user can re-add them latter.
So following this proposal:
I will distinct if they field can be made visible on editable and non editable views.
So I will follow your proposal but just for editable views and allow adding/hidding any fields on non editable lists.
. It is still a trick …