The application we have is used in several instances (different customers) and each customer has it’s own preferences regarding columns that are to be shown in certain tables.
As it is now, each user can create a presentation (or use a presentation provided to all users) and set it as default. This default presentation is stored as a user setting.
As a result, it seems impossible to have a presentation set as default for all users without each user having to set it as default themselves. Correct?
Is there any way to provide such behaviour? Best case is that an administrator creates some presentation and applies it as default to all users.
Hi @b.tel,
Presentation is a persistent entity (i.e., saved to database).
It is possible to include database scripts (or json files) and execute these scripts like any other cuba init/update script. So you’ll be able to provide a default presentation for your screens, and each customer admin can change these defaults.
You can use the Administration -> Entity Inspector screen and filter for sec$Presentation entity. Then you’ll be able to generate the SQL script or export a JSON file.
Yes, I know. The default presentation is something the customer creates itself, it is not something we provide. Once created, each user has to set it as default which - for most users - is too complicated as the controls are somewhat hidden and not everything is ‘obvious’ to them.
And I can hardly expect the customer to edit/create these sec$UserSetting entities through the entity inspector. That’s actually something we do not provide access too as this is also a place to really mess up the system (data).
what I normally do in these cases, where you basically want to remote control some CUBA config data in the database but missing an abstraction for the business-adminstrator is the following:
You can just go ahead and create a dedicated entity that represents this higher-level logic.
E.g. in this case something like EntityTableDefinition which contains a reference to the entity class, a user (or user group, or role or whatever) as well as a 1:N composition to a EntityTableColumnDefinition. This EntityTableColumnDefinition contains the name of the column.
With this higher level abstraction, you can now go ahead and provide this to the user. Under the hood, when such an entity is created / updated you create / update the corresponding sec$Presentation entity instances on the fly.
With that pattern you basically can get away and solve the business-administator problem(s) independent if CUBA provides a good enough management UI or not.
Thank you and yes - I like the approach you suggested and was thinking of something like that. But to apply it to all (or many) tables in the application would make it rather complex.
Note that you not only need to store the information (which is actually already provided in sec$Presentation) but apply it as well. When a user loads the screen, you somehow need a trigger to get a default presentation (if set) and apply it to the table. And probably do that only once per session (to prevent resetting it to the default while users make some on-the-fly modifications).
As this behavior would be needed consistently within the application it would be nice if you could extend the Table / GroupTable component with such behavior. However, I do not know how to extend components whilst keeping the Cuba screens and options available transparently.