Individual Layouts for a node, hide fields etc

Ok Chris, is that something Vizydrop can do? Look into the backend and see how much time an Entity is in a given State? If so they yes, this need would not have to have hidden formula fields to be solved obviously…

Here’s a screenshot of a report where a chart can be generated with the Y-axis showing the value of the date difference between creation date and modification date (just as an example, with dummy data):

You can do similar things with the other Report types (Table, Metric and Pie chart) depending on how you want the data presented.

Ok thanks! Don’t mean to take up your time with this as we will look at this ourselves, but one quick observation - you mention “creation date” vs. “modification”. Specifically I am looking for how long an entity is in a state in the Workflow extension. So when it moves from “in progress” to “in review”, now long is in “in review” till it next moves to “ready for testing.” The only way I could think to log that info is to use a formula field that would read the workflow for just those two states, and trigger first when the entity hits the state initially, and next when it hits the next state, and then yet another formula field to get the difference between those two times, and thus give you the total time in the State.

Hope that makes sense!

Yeah, sorry my bad.
I realise now that I had in my head a vision of your setup that was close to this and that you already had date fields for the state change, and you wanted to report on the delta between two time stamps.
Not sure why I thought that! Serves me right for posting after a long day at work :slight_smile:
Your comment about looking into the backend should have clued me in.

Anyway, yes, I guess that you need to do something on the entity side of things (either action buttons or formulas) to get at least some of the way there. Sorry!

1 Like

Chris, thanks and no apologies necessary. You deserve a medal for the work you do around here :smile:

Your solution is also useful and something we may like to have to just see how long a task has been in its current state (I believe that’s the intent). I was looking to try to keep a record of how long something is in each state, as I think you gathered. And my point is that this could be done with a range of hidden formulas fields that would be invisible, only surfaced in a Vizydrop that would access that data to create the report.

There are probably tons of other uses of hiding fields which just serve to make calculations. I know when Notion revealed their ability to hide those fields, they made a big deal out of it, and rightfully so as it’s a very useful feature. Especially with Field Proliferation a real issue to deal with in Fibery for the moment.

Thanks again!

I just happened to be revisiting this discussion, and I realised that the CFD charts that are now available in reports would somewhat satisfy the need to

We’ve had a need for this too in our company, mostly with a particular Type of ours; product order.

Already we have plenty of Fields. Some Fields are utility fields for other Types or Fields (which uses them for filter/sorting/calculations), some Fields are used for all kinds of orders, and some Fields are used on most orders.

Having to create different order Types is not a suitable solution either. We have category and then a subcategory of products. The Fields would even depend on the subcategory. There’s also no way to have some sort of wildcard Field that can show links from many Types in one Field.

There are other things (e.g. specifications) we wish was a dedicated Field, but they’re only used for an order of a specific product. This means a condition is met to determine if a field is useful to show or not. Therefore most of the time they’re useless and adds to clutter, and instead we have to write them into the description field and highlight.

1 Like

I would love to create custom Entity Views for a Type, where I can:

  • limit which fields are visible
  • have more control over layout
  • insert new UI elements (e.g. Buttons, static text, images)
  • insert arbitrary Views (sorted/filtered)

Entity views would then have a dropdown to select from the views that exist for the Type.


If you insert new fields from a custom view, do you mean that these fields are only available in / associated with that view?
Or are you actually just creating fields for the type itself?
The former sounds a bit like subtypes, which has been discussed elsewhere, with pros and cons of course :slight_smile:

I was thinking more of static UI elements like text and images, or Views; I guess “fields” is the wrong nomenclature. Except for Buttons, which would belong to the Type.

The basic idea here is to expand the concept of “multiple views” to include Entity views, not just Type views (collections).

Much of this has been discussed previously and I believe many aspects you mention are planned in some form. Overall I am interested in similar capabilities long-term.

1 Like

And I can’t help but wonder again how this conversation would be unnecessary if this board had some basic feature voting, or at least organization of features. As it gets older, requests are starting to proliferate that are the same.

As far as I can tell, here in the Fibery community the only hope to avoid duplication of requests is reliance on the Discourse native search: it will suggest that you are repeating a post as you type a new one, and you can search the forum for something you are about to post, and possibly Discourse will return the request if it’s already been made.

But as requests proliferate, repeat, and have unclear weight and visibility, I think the flaws of the reliance on Discourse’s search as a means to run a proper Feature Request Forum are becoming more evident. Compare this with the clarity you get with tools like Canny or UserVoice, which can do things like show trending, popular, recent, etc. requests. Not to mention some basic categorization of requests. I mean here in Fibery we have a category “Feature Requests” which has double the posts of the next biggest group - Bugs - and within the Feature Request category - zero subcategories! It is getting messy. On top of this, there is an unclear and inconsistent manual process that the Fibery team undertakes to edit posts with a status, further adding to confusion about how requests are really handled. At the very least they could publish an article defining what the statuses are, and what they mean, like Wrike does.

I, for one, am starting to lose steam when I come in here and see, more and more frequently, the same requests being made anew. And, the only thing tying them to the existing request is when good samaritans like yourself or @Chr1sG taking their own valuable time to try to merge or reference old requests. Other tools have staff that puts in time and monitors forums such as these to vet requests, merge, and communicate with posters about the existence of similar requests. The Fibery team does not do much of this. They respond here and there, but I have seen very little, if any, activity of them merging requests, or referencing similar ones to each other. I think hands down both you and myself have tons more posts in here than the combined Fibery team that link to repeated requests, try to bring similar request into one post, and so on. And ironically, we are actually leveraging some of the features of Discourse that that also make Fibery shine such as auto-linking, highlights, and others!

Fibery made the choice to use Discourse to track Feature Requests, and Discourse isn’t designed to do that. But since they made that decision, I expect more involvement here from Fibery directly to keep these repeated and concurrent discussions organized.

To that point, here is what Discourse is about:

On that page, you do not find the word “feedback” or “features” anywhere. Discourse is not designed to do what most of the people using the Fibery community - as evidenced by the huge disparity in post volume in the “Feature Request” category vs. all others - are trying to use this community for!

I really hope Fibery will rethink the way they publicly handle Feature Requests. Where would you rank Fibery in this regard among the tools in this list?

As a tool that is presenting itself as a Product Management and Feature Prioritization leader, I feel like Fibery needs to do this better than anything else in the market. Do you think that’s the case?

1 Like

I don’t really feel like Discourse is non-functional for managing feedback, but I agree it needs more hands-on maintenance to work ideally. Canny and others arguably also need such maintenance to e.g. merge similar/duplicate feature requests, etc.

We both agree that the addition of a “vote up” plugin here would be nice, but that may be somewhat mitigated by Fibery’s own direct support of Discourse, depending on how the interactions here are ranked. I know you are frustrated by how opaque that is, and I don’t disagree that I’d like to understand it better. But ultimately I do have some trust in the team that they want to understand real usage and feedback as much as possible and they do a lot of deep thinking about development processes, prioritization, etc. (as evidenced by many articles in the blog), so I have to trust that they are choosing sensible approaches to incorporating feedback, even if I don’t know the details.

I also don’t mind contributing to organization and interlinking here, as time allows. And while I agree it is the company’s responsibility, I also know resources are tight for startups. Since I want Fibery to succeed, I am willing to trade some of my time and energy to try to help that in ways like this. Certainly it should not be an expectation on their part that anyone but them do so, but I don’t think it is. That said I also think they might benefit from empowering a few people here as mods, with thread merge capability, which might help keep things tidy. But I can understand them not wanting to do so.

Things are imperfect, no doubt. Improvements could be made, and hopefully some will in time. I tend to feel like there are some compromises that are difficult to avoid at this stage. And I’m still glad I’m here and not with Notion. :grinning_face_with_smiling_eyes: Would I like to see ClickUp’s pace of development here? God yes. But they’ve been at it longer, have more funding, etc. And so far they haven’t actually introduced the functionality I need anyway, which are the powerful arbitrary Types and various kinds of relationships, among other things. So here we are, no better place to be for me, even with the frustrations.

1 Like

What you can’t see is all the times I started to post a feature request, but canceled it because Discourse found a pre-existing one that matched. But yes, all your points are good ones.


Yes, it does work the search, but I think the use of it here in the way the team has structured its Discourse instance to track Feature Requests is in and of itself limiting. What I mean is the requests are organized the right way - distinctly in groups, or merged so we have less duplicate posts. Or, we could have something like guidelines from the Fibery team to limit your Request to just one feature, and if somebody comes in and lists a bunch in one thread, a mod would need to merge that to the relevant existing requests and delete it. This way, Discourse’s search can be used to its fullest.

Thanks for that commentary!

1 Like

Hey thanks for all that!

I did want to address the point you made here:

The problem with the way this Fibery Discourse is set up is you don’t really have anything close I think to a Canny-type approach. I’d be curious how you think Discourse is functional at handling specifically Feature Requests, not general “feedback” which is what you mentioned above - although maybe you meant the same thing?

At this point here in the Fibery community, we have one mass of requests all organized in one category, growing by the day. There is an unclear way to see what is really being worked on. It’s up to the users to connect what’s here in Discourse, with the WIP’s published in Twitter, and more abstract discussions in the Blog, to figure out where their desired feature is on the list, like this one simple feature that remains to me a mystery as to whether we’ll ever get it:

I have been here over 1 1/2 years and still many, many key features remain unclear to me as to where they are in prioritization, or whether they will be done at all. I just don’t think these fragmented sources of info on what’s being developed in Fibery are easy to figure out, and overly helpful to paying users who are in pretty desperate need of some of the stuff that’s missing in Fibery.

I do agree as I just wrote that Discourse has great search, and in general it’s a market leading suite for managing communities. If Feature Requests were outside the realm of that scope, that would be one thing. But they are entwined here with all the other, more typical community areas like “Ask the Community” and “Share your App.” In fact, I continue to hope that Fibery will present a way to manage Feature Requests via Fibery directly, including a public-facing Feature Board, which is a key piece of Aha and ProductBoard that they are clearly going after. And then dogfood on that, leaving Discourse here as a true community piece.


1 Like

Hi, I replied here in some details Concerns about feedback and feature request tracking - #2 by mdubakov

1 Like

Now that we have Voting in place, it becomes more important to merge similar/same requests together so people can properly distribute their votes (limit of 10 per person!). So I think this thread here should be merged with this earlier one:

Hi again, sorry for the barrage today!

This time I’d like to suggest some abilities around limiting views of fields in entity views. Here is what is on my mind:

A cornerstone feature of Fibery that has attracted me is the deep linking and visibility between entities across the Fibery app. However, my use calls for free linking between any entity in any app, to another entity. Right now you have to specify which entity type you want to link to another. I know @mdubakov you’ve mentioned that the ability to choose an entity within an app is in the works, but this is also limiting.

So in order to accommodate my need, I am having to set up links to certain types of entities I’d like to be visible to any other, within those “destination” types. So in my case for example, I have an “idea” entity that I want to relate to practically all other entity types in all Fiber apps. I am going to create a relationship to “idea” in each of those types. This is not only a lot of work, but also as I build this out, I have some types with relations with 8 -9 other entity types, as I may need to link those at some point.

This has led to some clutter in those entity views, and my team and provided me some feedback that the views are getting busy and hard to read.

So one solution I thought about was if it were somehow possible to minimize, or mask, non-used fields, particular those with relations, if there is no relation present. One idea would be to minimize those so that just the name of the relation is showing. Fully masking those fields would basically block the user from adding the related entity, but if they were minimized, and could be easily “opened’ back up so an related entity can be added, then I think you’d gain a much superior view of the task details, but also maintain full ability to do relationships as needed.

Thanks guys for listening!


@B_Sp It would be great to see a screenshot of entity view and a screenshot with the whole domain. It will help us to get the problem better and maybe even advice something