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.
Required field can not be optional.
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).
1 Like
We do not care. We just not support that because it is simpler and more performant (no cache invalidation).
I don’t know yet if it’s important or not.
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 …
1 Like
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.
As editable is a property of the view that will be by design.
It is wrong to think that any field can be added to a non-editable list. Some fields can not be displayed, some fields are too expensive etc.
This feature is not about leaving the customization to user. It is about giving some enlightened choice to the user about some columns.
I guess I was not very clear 
.
My worry is indeed with the editable views. But any view can be made editable by a developer thus it extends to all the views. Making all fields “optionable” gives the user too much power to break the interface.
That’s why I agree with @ced on this:
Of course it’s doable but it seems too complicated to me.
Also I don’t think we should allow to add any field from the model.
I’m not sure if we should really care if any view can make editable by developer as the developer can also set the option attribute of all of the fields (by registering a mixin) to any value.
We can not prevent developers to do thinks we don’t like.
Other option is to just prevent altering the view definition if the view is editable. The unique issue that we may have with non editable views is slow performance due to adding some long computation fields.
I think it’s a good compromise to allow the user edit the fields of a list view but not allowing to modify the fields of editable views as they are used to enter data (like form views) so it should be managed by the developer.
Hi Everybody,
We at Kalenis have developed a feature like this, with great feedback from our users.
First of all, we take a different approach on SAO list views, because some features was a must for us, such as column resizing and horizontal scroll.
So, we write a component replacing SAO list views, who works together with Kalenis User Views module, adding features like:
- "Windowing" approach to get records
- Horizontal Scroll
- Manage columns: Add, remove and reorder columns
- Context Menu on right click (inspired on GTK client)
- Allow the user to change records quantity on the view
- Comfortable or compact view
-
User Views Support: Kalenis frontend depends on Kalenis User View module, wich is necessary for:
- Create and save several views, including columns visibility, width & order, filters, order and records quantity.
- Each view could be user specific or available to all users.
- All of this operations are restricted by permissions, considering the following options:
- View Manager Active: Allows the users to access to view manager options (Without this group, the user will have no access to view manager features)
- View Manager Editor: Allows to create and edit views owned by the user
- View Manager Add Fields: Allows to add fields (wich are not on the original view)
- View Manager Global: Allow to create views available to all users.
Of course, there is a lot to be done and improved yet, but currently this is a good solution for our users.
Just my 2 cents,
Best !
6 Likes
That’s the idea we had with a PoC view configurator module we created: allow editing readonly tree views only.
We allow view edition to administrators only, so if the view is too slow or has too many fields it is their responsibility.
IMHO, it’s enough for most use cases.
I just tried it and it’s great. You should consider these features to be part of Tryton.