I make a solution with JS-manipulating DOM. In this workaround a dropdown/select is displayed insteed of checkboxes.
Quite simple so far.
But only filter values are useable, which are already defined in FetchXML filter.
Filter is defined as:
<filter type="or" adx:uiname="Color">
<condition attribute="cr847_bstatus" operator="eq" value="red" />
<condition attribute="cr847_bstatus" operator="eq" value="green" />
<condition attribute="cr847_bstatus" operator="eq" value="yellow" />
</filter>
Results in HTML:
<input type="checkbox" name="0" value="0">
<input type="checkbox" name="0" value="1">
<input type="checkbox" name="0" value="2">
When first checkbox is clicked, it is submitted as:
metaFilter: "0=0"
You see 0=0
"0" is the number of filter condition in filter number 0 (first filter); in this case like red.
Submitting 0=3 is useless, because no fourth condition defined in filter.
When changing order of conditions in filter:
<filter type="or" adx:uiname="Color">
<condition attribute="cr847_bstatus" operator="eq" value="yellow" />
<condition attribute="cr847_bstatus" operator="eq" value="red" />
<condition attribute="cr847_bstatus" operator="eq" value="green" />
</filter>
then 0=0 is now yellow.
A real filter, as I expected, isn't possible this way.
A definition:
<condition attribute="cr847_bstatus" operator="neq" value=" " />
gives exactly one checkbox and not all results, which not contain " "
Each condition defined in FetchXML filter becomes one option in portal. That's all.
I think Microsoft can do a lot to expand functionality of such a filter. Couldnt be so much complicated ...
My solution is now a combination of JS/Liquid fetch/Textfilter.
Works fine 🙂