Per user list view definition

I guess I was not very clear :slight_smile:.

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 !


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.

Hi Ignacio,

What your are explaining seems like a good improvement. I will like to test your implemenationt to consider if there is something that can be easly included as part of the oficial release.

Did you have any public server where we can test this? I see there is an available demo for kalenis but i did not find the credentials to login any where.

Thanks in advance.

Of course, and I don’t want to do that.

The course of action I want to prevent is the following:

  • The developer make a specific tree view editable
  • The user can make optional per your proposition, thus he removes a required field
  • The view is broken

But a silly developer could make this:

  • Make a view editable
  • Make each field on the view optionable
  • The user does something stupid
  • The view is broken

I want to prevent the first case, not the second.

I do not see any diference between both cases:

From the user point of view they should se a message telling that the field is mandatory so (in both cases) they should be able to fix the issue by themself just adding the required fields that they removed.

The first one relies on the design to make the behavior correct ; the second relies on the validation.
From the user POV it might be almost equivalent but from the software architecture POV, the first one is way more solid.

A design that allows breaking views does not sound like very solid. Having an attribute to prevent errors which can be by passed just adds uneeded complexity to the software.

There are several solutions here:

  • Ignore custom columns definitions for editable views.
  • Only take in account optional attribute on editable views.
  • Allow users to add/remove all fields (like we do for import and export).

The first two avoid wrong users setups (no broken views) and the latter give them the resposability to fix any errors they may generated.

Indeed I think we should support albert’s design:

and allow editing all fields on non editable views because users can not broke anything there. Just make views slower and I see your are improving this case :wink:

Bypassed by developers. But developers can bypass anything anyway.

Yes, but then we are adding a functionality for users that they can not activate without a developer so this will produces the following results:

  • It will require a developer to activate the attribute on all the required fields (which increases the cost and decreses the independence of the user). This is a small step to the current situation where we need a developer to create a custom view per user. Of course we may set some sensible default for base fields but this will require to review all the fields of all the modules which is more work for us.
  • The feature will be hidden (or just enabled partially) for users that do not want to have a developer or a customization module.

We are developing something for users but we are restricting it’s usage to developers.
I may understand we want to restric some decission to most advanced users, that’s why I initiali proposed:

Advanced users with administration privileges may take advance of this feature without requiring coders.

Indeed I have no more to add on this discussions and I already proposed several options which may prevent errors. So just feel free to pick one or none of them.

Hi Sergi,
Sure, you could give it a try here, (usr:admin, pwd:adminkalenis).
Also, if you want to test it with your instance, you could follow a few steps here and you are ready to go.

Would be great to hear your feedback,

Best !

1 Like

Thanks ! Have you been able to install it without troubles ? We want to improve that soon.


Thanks for sharing the demo, I give a quick test and it looks impresive.
It will be great if some of the work can be integrated upstream specially the following features:

  • Column selection (which is already discussed here)
  • Allow to update the column width.

I think the second is already relevant for this implementation because with the current fixed with limits the number of columns to be shown:

Thanks for the feedback !

Would be great ! For our users, flexibility is really important. We plan to go deeper in this direction, with features like “frozen” columns (already discussed in this thread), footers added by user, etc.

Maybe integration is a challenge, cause we wrote a set of react componentes replacing SAO original tree views and all the features rely on this.

:see_no_evil: :see_no_evil:

This is a problem because we do not want to rewrite the sao using react nor have a component that uses it. We try to use as minum dependencies for sao to ease the maintenance.

We use html tables to render the sao tree views so as far as the resize feature can be added to a plain table there should be no issue for that. Do you think this is possible? Could you have a link where the column resize is implemente so we can review without the distraction of other features?

Hi !

Of course, i get it !

I guess it could be implemented using html tables, Jquery, etc. But currently we have good results using React, so we are not planning to move away from it.

with good old vanilla javascript (a seemingly long forgotten possibility)

Apparently I’m increasingly benefiting from my age and disgust with javascript frameworks - in many projects people are surprised that you can just write it yourself without much effort :slight_smile:

1 Like

This topic was automatically closed after 9 days. New replies are no longer allowed.