Not sure if this is a bug…
It’s nearly impossible to use MultiView on a Users level because of the limited set of available operands. Nothing like “is empty”, “is not empty”, “contains”, “doesn’t contain”, etc.
The whole thing doesn’t have parity with other filters.
For one, it only looks at positives (e.g., where something IS value) and not negatives (where state IS NOT ‘final’).
And second, it’s only a single condition. No ability out-of-the-box to say “where x and y and z”.
Both can be worked around, sort of, with a function field, but to make a function per condition rather than baking it into the views themselves seems like an oversight.
In your situation, I can see how you might want to use it to check a user role?
Depending on your data structure, if your users have a user -> users relationship, say “Manager” and “Manager For”, you could create a formula like [Manager For].Count() > 0 to see if somebody is a manager for others, then this boolean can be checked as a tab condition.
Otherwise, User.Roles.Filter(Name = "Manager").Sort().Count() > 0 if you’ve set up a roles table for user groups, although the explicit hard-coded string comparison will be impossible to debug if the role name changes in the future. You could use the public ID, or make another column that you won’t ever change. All up to preference, really.
It is not a bug.
1 Like
We’re still collecting feedback and use cases, and will possibly/probably improve the rule options according to demand.
1 Like
Outside of feedback collected, my vote is always: If it’s going to be done, do it right (consistent with the rest of the system). Even though I haven’t used these rules yet and there more important things to me on the roadmap, I’d be happy if you guys went back and completed this as it makes for a more complete product. Missing things like these make the product feel rushed when doscovered.
The consistency is honestly what made me love Fibery in the first place. Almost all of it is consistent and thought out. Just some things fall through the cracks. This is one (for now).
(File Lookups is another recent one)
1 Like
This is unfair. In this specific place it is quite hard to provide the whole power of filters and if we should go there we should have pretty decent evidence that it will be needed.
I see. In which case maybe it is good to explain this in docs and add a link to it in the menu. I think user appreciate “We didn’t do it the same way due to performance or other limits” (almost) as much as the consistent behaviour.
Just sharing how it is received by me. Maybe other see it differently.
I will reiterate that it’s just the fact of how brilliant Fibery is, every added feature has a lot to live up to.
1 Like
That’s the word - consistency. Thanks Ron. @mdubakov, it’s pretty awkward feeling to find out very unexpectedly that a set of the same filters I’m used to use in other places in Fibery isn’t available on a User level… I’m not even talking about subfiltering (when there’re db relationships involved). In some places it’s available, in other it isn’t. Don’t get me wrong - I love Fibery! And with that it’s becoming a tough 
love needing to accept these unexpected inconsistencies across filters/coloring/ability to make a group of filters, disable/enable filters, etc. across different areas of Fibery.
Quick clarification. The limitation is not specific to the User db. It is a limitation for entity view rules everywhere
1 Like
Consistency is very expensive. It is somewhat similar to “zero bugs“. You can be maybe 95% consistent, but effort is just enormous.
4 Likes
Makes sense.
1 Like