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.
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.
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
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.
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.
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.
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.
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?