Currently when setting up a table, a variant is used to define an exception as display method of a specific table. The main set up is used by default and only when you would like to use a different display method, you set up a variant. This approach often leads to issues with the use of prefilters. For example a specific prefilter is set to disabled and hidden on the default display method. However this prefilter should be enabled and visible on the variant. This is not possible. The same issue surfaces with hiding columns on the default display, but enabling them on the variant.
The solution is a default variant. This variant is created upon creation of a table. This is also the default display method of the table. It is not possible to display a table without a variant. By using this approved the issues, which I've described in the previous paragraph, will no longer be an issue.
To reduce the workload whilst setting up these variants, the main settings (which're currently being used at the default display method) should still be accessible and be used as the default values for each variant.
On the backlog
Improved use of variants
We recognize the problems you describe but propose a different solution, namely to no longer see variants as a deviation from the default, but to treat variants as first-class citizens with their own Indicium services and authorization settings.
This would allow hidden or disabled columns and prefilters of the default configuration of a subject to be enabled for a variant. It also ensures that hidden or disabled columns and locked prefilters of variants can never be bypassed through the default configuration.
This would allow hidden or disabled columns and prefilters of the default configuration of a subject to be enabled for a variant. It also ensures that hidden or disabled columns and locked prefilters of variants can never be bypassed through the default configuration.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.