I agree that this is something that would be useful and I assume not super complicated. I end up with a lot of calculated fields to use for filtering within views, which are more complicated than the filtering supports. These calculated fields aren’t really ever needed to be shown and end up being a bit overwhelming for new users. There have been a couple other threads with similar topics to reference and “heart” as well.
4 Likes
I wholeheartedly agree. I would love to see this feature request implemented!
1 Like
Glad you brought this up @Stepan_Galkin! Since this is basically a duplication of the requests @rothnic quoted, could you please be sure to “heart” those as well? There’s no clear way to know if the Fibery team is counting your request alongside those, so it would be great to get your “heart” of support to leave no doubt!
…and I can’t help but mention yet again that we have here another example of fragmented requests in this community that an organized voting / request tracking approach would solve, right @Oshyan?
One particularly useful feature that is relatively new in Jira is the ability to pin fields. Jira is highly customizable, and they added this feature which really helps when you get a ton of fields, which can also happen in Fibery, in particular as long as we don’t have Polymorphic Relations.
Some fields are already pinned, such as “Created by” and “Created date”, but to the bottom of the Entity. In some cases actually I’d like those fields at the top!
Thanks.
2 Likes
Yes, please. File this with Customizable Entity Views
1 Like
Great point Matt, we need a whole group around this subject…I really wish the team would at least think seriously about grouping requests. I know they won’t do votes as has been discussed many a time, but at least grouping would help organize this board. There is only so much relying on simply searching around in Discourse will do…
I might draw the loose analogy of using Gmail with no folders, and having to rely on search only to find stuff…
1 Like
We have this in mind as Important fields. Overall, we are discussing major Entity View re-work, that includes new 2-panel navigation, blocks, primary/secondary info sections, etc.
4 Likes
Ok that sounds like some exciting improvements indeed Michael. Wishing you guys big success in implementing them soon, my team could really use them!
1 Like
3 posts were merged into an existing topic: Tab Views in Entity Pages
Yes, this is planned till public beta release.
1 Like
Bumping this for additional consideration since I see its on the “NEXT: Consider for near future (1-2 months)” in the current version of the roadmap.
Specifically, I would love to see something like Coda’s “Customize view” as shown in the Fibery vs. Coda. The Power of Workarounds post.
13 Likes
yeah, i’m excited about this
1 Like
I want to bump this now.
Still missing this feature. Showing so many fields can lead to confusion, especially when using some just for technical reasongs (calculation).
In Notion they implemented a simple show/hide function, which is better than nothing. IMHO a per view settings would be great.
2 Likes
This is in nearest future scope, right after Pin Fields on Entity View
2 Likes
Yeah! Great! I open a beer to celebrate this info 
1 Like
It is possible to Hide fields on Entity View now
5 Likes
I had commented this in the wrong thread, I add my idea/suggestion here as it’s more fitting:
I give an example:
Let’s assume I have a dataset of documents. There are different categories of documents, indicated by a single-select field “Document type”. Depending on the document type, I might want to see different fields, and even different rearrangements of the fields.
I continue with a suggestion:
Let’s assume you could rearrange and resize fields within entity view.
You could have any view you want, always just for this entity. However, if you could also save the “entity view” now, give the “entity view” a name, you could:
- Simply select the desired, pre configured, entity view from the list of saved entity views (within an entity)
- Automate entity views via automations by desired criteria.
E.g.:
If entity field “document type” updated,
then entity view (for step 1 document) = A, if “document type” = X
= B, if “document type” = Y
else, do nothing
Something along these lines? Hope it’s understandable. Not sure if this has been suggested like this before.
1 Like
It’s possible to create Custom Relation Lists now 
(slowly improving…)
1 Like
Just wanted to note that I saw this is next, and it’s a bit exciting:
However also wanted to note that my visceral reaction was “Dang, just collapse? I wish we had full, unique, savable layouts per-DB”. I know, it surprised me too, but that’s what I wanted. 
Which is to say, individually-remembered collapse states per-DB layout is great, and it may be that for many roles a single state will represent their needs fairly consistently. But for me as a “jack of all trades”, interacting with a lot of different data in different ways at different times, I’d love to see more fully articulated and separately displayable (even linkable?) view setups/templates.
I think this would also apply well to e.g. publishing of Entities, where the configuration if the view wouldn’t necessarily be desirable as an end-user feature, and yet you want to be able to show particular view configurations to the general public, vs. different ones internally, etc.
All that said I’m still excited collapsible “left pane” fields are coming!
1 Like
Do you mean that each user would have their own personal set of multiple layout choices, per db? Or just that a db would have a set of views which all users choose from?
2 Likes