This is quite a long topic with many replies, but I’d be interested to know if the relation filters that were released recently can solve some/most/all of the use case?
I was looking for something you could do with single and multiple-select fields, so with relations not really what I was hoping for. Do you think the very first example at the top of this thread could be handled by the filters? Maybe I don’t understand this well, so if that’s possible, please enlighten me, thank you!
For the example in the first post of the topic, you would need the categories (Meat, Vegetable and Fruit) and the examples (Beef, Pork, Spinach, etc.) to be in databases
(and it assumes that you would be choosing a single example, based on the value of the category)
The case for relation filters being supported for single-selects is in the backlog.
Ok thanks for getting back to me. Yes so that’s what I thought. It’s a point frequently made by @Oshyan that I subscribe to pretty strongly as I move along in Fibery and months/years pass, and that is to avoid creating a db unless it’s absolutely necessary. In fact my team has many potentially db-level groupings that are instead categorized by using single or multi-selects within one DB so we can avoid setting up too many db’s. Proliferating db’s leads to all kinds of issues that could be solved with polymorphic, which is one feature I really hope gets out of the backlog at some point!
So in this case I would definitely not want to create a db just for those few ways of categorizing the entities.
Thanks again!
This is something I have been coming across repeatedly as well. I fully agree with this sentiment:
I think given that single/multi select fields appear to be databases under the hood, it does seem logical that the filter could be extended to them as well. This way the users can extend the database without having to manage it as a full-blown database.
This might be mostly psychological but I can imagine it becoming very difficult to manage multiple “Status” databases when all you are trying to do is to allow the “Status” drop-down field to be dependent on another field.
Is there any possibility that we will see the filter functionality (as described above) will become a feature in the near future? This would really help keeping the clutter to a minimum.
I know using a separate database has been suggested as a solution. However, I do find that new users are totally confused by the ability to click through the field and get to a “status” entity page. I think having single/multi-select fields be just drop-downs makes them very useful. The fact that you have to make an effort to open them as entities means that users are not confused by the seeing the “>”.
See also:
Based on this thread I started in Get Help.
I explored using back refs or highlights, but I want to have a more structured and consistent relationship pattern, so migrating my Get Help question into a feature request/idea.