In fact, it is the opposite - any to-one relation field can be made required, but to-many relation fields cannot.
Not sure which side of the relation filter you are referring to, but in general a dynamic relation filter can take either of these forms:
To-one field ... is ... This entity → Field value
or Collection field ... contains ... This entity → Field value
But the right hand side field value needs to be a single entity (a to-one relation).
You can vote here for the option to support
To-one field ... is any of ... This entity → Collection field
At the risk of being pedantic, there is no such thing as a ‘to-many relationship’. The whiteboard can show relations which are m:m, 1:m or m:1 but it is indeed not currently possible to show 1:1 relations.
There are a variety of answers to this, depending on the feature.
I’m not sure what you mean by ‘to one’ display options are limited to ‘compact lists’. Are you talking about entity view? If so, then it’s just how the entity view improvements have been prioritised. If you want to be able to see other fields belonging to the linked entity, then perhaps this is something you want to vote for. Or may be there are other feature request topics that are closer to what you need.
Again, it’s just a case of prioritisation.
This is also a question of priorities, but bear in mind that we already have comments/complaints about the complexity of the context filter UI, so adding more relations would make this even worse
We plan to improve context filters at some point, and when we do so, it may open up the option to add in routes which traverse a to-one relation.
Yeah, I guess “To-one field … is any of … This entity → Collection field” is the scenario I’m talking about. I’ve voted for that idea now, thanks.
Yeah, I’m talking about entity views. I think Fibery’s names/labels for many of it’s features and components are very confusing. May I recommend creating a visual guide users can reference so we’re always speaking the right language?
I understand that many “to one” relation features haven’t been prioritized. The whole point of my post was to try and understand why they weren’t/haven’t been prioritized and request that going forward, they are treated as a use cases that are just as important as “to many” relations.
Far too often, we think we can do something in Fibery but then realize because of a “to one” relationship it can’t be done. Then we have to fight with questions from within users in our org that assume:
I’m lying, with comments like “I don’t believe that Fibery can’t handle such a basic use case, because it can already do this more complex one”
Fibery sucks, with comments like “If Fibery can’t handle such a basic use case, why are we even using it?”
Fibery only does the bare minimum before it moves on to other features, with comments like “Are you seriously telling me Fibery released X and called it done? What about Y and Z use cases?”
It’s not easy to give a simple answer to that unfortunately. There’s certainly no specific favouritism which means we treat to-one relations as the ‘red-headed stepchild’ as you described it.
Rather, when determining which features to implement, we weigh a lot of factors including:
how many use cases it unlocks
who are the users who will benefit, and how many
what other features will become possible
how hard it is to implement
are there alternatives/workarounds that mean it’s possible to achieve in some other way
and probably a few more that I haven’t mentioned.
You might want to read Anton’s article (if you haven’t already) for some insight into the thought processes.
And of course, every desirable feature is competing against a load of other features for the limited bandwidth of the dev team.
I know that sometimes a feature set is released while being incomplete. This is rarely an accident, but rather a deliberate choice taking into account all of the above.
Finally, our experience is that many users think that the one feature that they are missing is so useful and so basic (and “it can’t be too hard to do, right?”) that Fibery is crazy to not include it. But the reality is often that many other users don’t feel the pain of its absence (and it may actually be a lot harder to implement than people think).
Anyway, message received that you (and your colleagues) are missing some functionality.
My first reply was not to dispute this, merely to double-check that we were on the same page, and that it wasn’t a case of undiscovered functionality.
