what used to be context/selected when setting filters on iterating containers has recently been split into 2 separate choices. This has some benefits, but it’s no longer possible to set up the old “either/or” behaviour, even though the UI suggests it should be:
On the selection level it still looks the same, but when you open the filter you have to choose one or the other. This makes for a somewhat cumbersome and misleading UX, since you have to actually open the menu to know which condition is selected.
To be clear, I haven’t seen this break any existing setup – but the option to configure it the way it used to work seems to be gone, despite the UI implying otherwise. The extra flexibility is appreciated, but it would be great if the old behavior was still available as an option.
Thanks for raising this — I can see why the UI feels confusing here!
The two modes are actually distinct:
Context → uses getSingleObject() → returns the context object, a single selected object, or a lone object. Always one object — this is the old either/or behavior.
Selected → uses getSelectedObjects() → returns all selected objects, so potentially many.
The old either/or logic is still there, it’s just now represented by the Context choice. I’ll register a UI improvement request to to the Platform team to make this distinction clearer.
It’s possible I’m misremembering, but I was convinced the old behaviour supported both single and multiple objects. Currently it always returns just one (like you’ve mentioned) – yet “exists in” is still available as an option, which implies it handles both cases.
It looks like either the behavior has changed, or it’s a UI bug.
Thanks for clarifying!