Prefiltring...

[lcollong]

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 ?

 

[troester]

For security reasons you MUST have the strongest prefilter directly in the list settings.
The menu prefilter can be "canceled" by just deleting the itemid from the URL and you can display any list by typing the "unSEFed" URL.

So it would only make sense to "OR" the menu prefilter (to cancel single conditions of the list prefilter).

 

[lcollong]

Yes, as I said, I do it this way. The "real" prefilter should be at the list level so that "forbidden" rows would never be shown to the wrong user. The menu prefilter option should give the possibility to reduce this already reduced set of data (filter the filtered data). But actually, it cancels the list prefiltering and give access to all rows prefiltred by the menu which could be a wider set of data.

If you have a list prefilter saying "where published=1" applied to register level for example. If you create a menu with a prefilter saying "where date=today" applied to the same level, the resulted list will show published and unpublished records of the day. Whereas one could expect to show only the published records of the day. "Where published = 1 AND date=today"

 

[cheesegrits]

Yup. That's the current behavior, which IMHO is wrong. We're having on ongoing internal debate about this. I feel strongly that prefilters defined on the list should always be applied, regardless of menu prefilters, and the latter should simply add to, not replace, the list prefilters.

I'm hoping to convince Rob to let me change this behavior. It may break backward compatibility for some folk, but I think it's worth that pain.

-- hugh

 

[lcollong]

Thanks for explaining. I share your opinion and vote for this solution if I may participae to your debate !