Is it possible to allow us to import from a single/multi select? When setting up a new type to replace a select field (I had originally setup a select field but ran into limitations when grouping and nesting entities) it would be great to use the existing importer to bring in fields on a conditional basis.
On a related note, It’d be nice to have a background color property for types so we can use them in the exact same way we would a dropdown.
Import from a select field? From where to where?
If Select fields could optionally be designated as “global” types, then centrally administered, and included in any DB, that would be ideal.
Then they would be normal databases 
It is actually possible to link a select field to another database that the original, but you have to do it by opening a select field option and adding a new relation from there. It’s really not recommended for a number of reasons.
If you need a shared enum, then a dedicated db (probably hidden from search) is the way to go.
If you just want to copy the options from a select field as new entities in a new database, then I suggest making a table view with the select field as groups, collapse the groups, select the option names, and copy-paste into a table of the new db type
The one advantage that simple single/multi select fields have is that for the most users, they just show up as drop-downs which are easy to use and understand. Relations to entities (one-to-many or many-to-many) have a much more sophisticated rendering and can sometimes confuse users, especially the ability to drill-down into entities:
Things are even worse when it comes to multi-select relations:
It would be amazing if a “Display as” option was provided whereby you could basically tell fibery to treat/render some relation fields as single/multi select fields.
1 Like
If you click the ellipsis (…) for a relation field, you can choose to display as a compact field
Oh, I had missed that feature! Thanks @Chr1sG
I think we are almost there, if you could also just disable the drill-down. I know it doesn’t sound like a big deal, but I’ve had quite a few users just totally lose where they are because they ended up drilling-down into unrelated entities.
Do you mean the arrow to navigate to another entity?
I think for a lot of users, being able to quickly jump to another option is quite valuable - this was one of the more popular requests before it was implemented. I don’t think we’d want to change that back.
I totally agree and not advocating that we remove it everywhere or go backwards. I just think in some relations, it might be unnecessary or confusing to have it.
So I’m saying it would be a good display option to have, which makes some relation fields look and behave like single/multi select fields.
Do you think that the usefulness of showing/hiding the arrow is something that varies from relation field to relation field, or is it a property of the database being pointed to?
By that I mean, in your image, you show a Status Relation with an entity called Approval.
Is hiding the arrow likely to be useful for every field that is a pointer to this database, or might it be useful to show the arrow for some entity views that have a Status relation field?
My intuition is that the use case is to make a database behave like an enum, not a use case to make specific fields behave like select fields.
Do you get what I mean?
Agreed this os the best option we have today but theres still a lot of manual labor in recreating calculations.
A true conversion or a dedicated import wizard that can ingest and remap formulas would be the dream!
Also re: whether disabling the arrow is a per type or per relation preference, I’m going to say it’s a per relation preference.
For user/workflow management there may be times where we just need to select an option. But I’m a data nerd 
there may be relations where I need to easily the linked entity.
I use entities as global drop downs frequently. I don’t care for the arrow when connecting Deals to Services, I do care for it when connecting Payments to Services. One workflow is for data entry the other for reporting.
1 Like
I’m not sure what you mean by a dedicated import wizard in this context.
Are you talking about the ability to replicate a db schema, or the ability to import entities into an existing schema?
The options of a select field, might be considered part of the schema definition, but I guess you’re wanting to treat them as entities to be imported into an existing schema.
I’m not sure how we go to talking about formulas here. Did I miss something?
Perhaps this needs to be a new topic.
i.e. the ability to show/hide navigation arrows when displaying an entity (as a compact list)
It seems to be a little off topic from the original thread (“Single select field options as levels in smart folders”)
Sorry, I was relying heavily on the context of of @cannibalflea’s comment but I never quoted it. [quote=“Chr1sG, post:19, topic:1844”]
I’m not sure what you mean by a dedicated import wizard in this context.
Are you talking about the ability to replicate a db schema, or the ability to import entities into an existing schema?
[/quote]
In my example I have a Type on the left, which was created to replace a single select on the right. Whenever we need to convert/recreate a single select field as a new type we have to do both db schema recreation and import the user generated data. So my request is something that does this for us. My language about importing is a semantic choice nodding to the fact that select fields can have formulas and other properties that copying and pasting won’t replicate. So Fibery would need to be able to read and recreate all properties from the select field to the new type
Could all of the above be summarised as a request to make it possible to convert a select field to a standard database?
Yes, absolutely!
Adding a mention of this topic to enhance discoverability:
For us it would be ideal to make a database behave like an enum. That would help a lot since we do love this feature but for some databases it’s confusing since the user will find an empty page (we hide all entities in those cases)
2 Likes