lcollong
FabriKant d'applications web
Hi,
One of the powerful Fabrik's features is "prefiltring".
As the tooltip says, it you define a prefilter within a J! menu, it will cancel and replace all the prefilters you've set at the list level.
Is this a "decision" or a consequence of the Fabrik architecture ? It would be safer if the prefiltering in the j! menu would apply on the data set already filtered by the list itself.
It's always possible to copy lists and tune the prefiltring for each one. But this creates a bunch of "child" elements, plus froms, groups, etc...
In my case, the J! menu shows a list which have a "complex" prefiltring scheme based on the user rights. These prefiltrers are defined in the list itself. I'd like to add two new menus to show a subset of the list. Kind of dashboards. One to show only the today related records, the other one to show only the "confirmed" records.
Using J!menu prefiltring to "add" these conditions would have sound "logical" to me as it does not create a security breach of the data displayed (still controlled by the list prefilter). But, with the actual behavior, if you forget to specify one of the prefiltering conditions, you may inadvertently show data to a user he would not.
The solution to copy list and dedicate them to specific views without using J! menu prefilter options is working fine. But it creates a lot of elements which are not very useful in this particular case and ought to maintain prefilters conditions in 3 different places .
So I'm wondering if this behavior is a decision or just the way it works due to internal Fabrik constraints ? Or is there any reasons people would prefer this "cancel and replace" behavior ?
One of the powerful Fabrik's features is "prefiltring".
As the tooltip says, it you define a prefilter within a J! menu, it will cancel and replace all the prefilters you've set at the list level.
Is this a "decision" or a consequence of the Fabrik architecture ? It would be safer if the prefiltering in the j! menu would apply on the data set already filtered by the list itself.
It's always possible to copy lists and tune the prefiltring for each one. But this creates a bunch of "child" elements, plus froms, groups, etc...
In my case, the J! menu shows a list which have a "complex" prefiltring scheme based on the user rights. These prefiltrers are defined in the list itself. I'd like to add two new menus to show a subset of the list. Kind of dashboards. One to show only the today related records, the other one to show only the "confirmed" records.
Using J!menu prefiltring to "add" these conditions would have sound "logical" to me as it does not create a security breach of the data displayed (still controlled by the list prefilter). But, with the actual behavior, if you forget to specify one of the prefiltering conditions, you may inadvertently show data to a user he would not.
The solution to copy list and dedicate them to specific views without using J! menu prefilter options is working fine. But it creates a lot of elements which are not very useful in this particular case and ought to maintain prefilters conditions in 3 different places .
So I'm wondering if this behavior is a decision or just the way it works due to internal Fabrik constraints ? Or is there any reasons people would prefer this "cancel and replace" behavior ?