Would like the ability to define the options of a Single-Select or Multi-Select field in one place, and have the definition instantiated/referenced/used in different Types?
Example: Defining a Single-Select field for choosing a “Role Type”, such as:
Content Writer
Web Developer
Project Manger
SEO Specialist
Admin
Sales Manager
Let’s assume I have four different Databases in my app that each need one of these Single Select fields with these exact options.
I want to be able to define this field (the options) in one place, and have this definition used (and updated, should I change it in the future) in each one of my four different Databases that has this kind of field.
This is a feature request created based on this question here:
Hi, Dimitri!
I think in your case it will be better to create a specific Database, called Role
In fact our Single Select and Multi-Select fields are Databases (1-many; m2m) with a friendly UI for simple cases
If that’s not enough - one Database, relations to other Database you want - and you’ll get rid of any limitations, and will have access to visualizations, that didn’t work with Single-select and Multi-selct fields (like Hierarchical lists for example)
Yeah this works very well, but there are two problem with this approach:
1) Its unintuitive - only seasoned Fibery users know that multi-select fields are secretly hidden mini-databases.
Maybe having a normally off checkbox on the single/multi-select field creation modal for something like “Make these options available globally (in other databases)” which automatically does what you suggest, but creates them as “hidden” space/databases. Something like this:
2) It creates a bit of clutter - having to create several spaces/databases just to contain a few entities used as global single/multi-selects creates for messy relationships and clutters up the UI. Because then you have one or more space/databases which really don’t do anything more than hold a few entities.
Also, as was pointed out in the other thread, multi-selects appear in the right hand panel of entity view, whereas a many-to-many relationship (to an enum database) appears as a collection, which is often unnecessary for a simple multi-select functionality.
