Now that we have multiple entity Views, we are close to being able to “simulate” polymorphic or variadic Types/DBs by automatically hiding fields that are irrelevant to an entity’s “subtype”.
The missing piece is a way to designate the default entity view for each entity.
As a first step in this direction, it would be quite helpful if Fibery would simply remember the last entity View selected for each entity, and use that same View for that entity until a different View is manually associated with the entity.
Ultimately it will be most useful to designate a single-select or formula field to determine the default entity View for each entity. This will allow for programmatic control which will be important to realize the full potential here.
I suspect @Matt_Blais means that when an entity view is chosen for one entity it does not affect the entity view chosen for other entities of the same type.
Great, I had brought this up before as well. To me, if a view is marked as “default” it should load that view for all users, at all times, regardless of what they had previously been looking at. Even better if that view can be dynamically set based on an “entity type” field.
So easy navigation of child pages is not possible, because as soon as I choose the tab with Descirption field in a child, the parent page also switches to Description tab.
I hope the automated selection can take care of this soon.
Any general timeline on the ability to set an entity view dynamically based on a entity field/current user?
We’re trying to sell Fibery as a potential custom CRM/ERP solution to our clients but keep running into scenarios where the lack of context filtering/dynamic views is a deal breaker.
It’s common in many industries to have multiple people needing to contribute/collaborate on a project, but not all of their roles are the same and it’s virtually impossible to maintain an accurate, secure source of truth in Fibery when viewing and editing permissions are an all or nothing option. Like, it’s not out of the ordinary for a manager to need to see and edit fields that a regular employee shouldn’t, right?
Dynamic entity views based on field values, along with Field-Level Permissions & Field Locking are essential for many businesses to seriously consider Fibery as a solution.
Field-level permissions will not be happening any time soon (years, probably).
In the meantime the workaround is to split fields across (linked) databases, and use lookups to surface field values from one db in the entity view of the other, if necessary.
Assuming that the ability to view/edit fields in related entities gets delivered, the UX for this will potentially be good enough to satisfy most use cases.
See here and here and maybe other topics.
Dynamic entity views will likely happen at some point, just no ETA, and will also likely contribute to making the linked-dbs-to-implement-field-permissions workaround even nicer.
