I appreciate you responding to my question! We too have the exact same situation, many types of tasks, but we have named them as such - there would be in our case an “inventory task” and a “project task” since there were no breadcrumbs up to date so that was a way, aside from the icon and color, to distinguish between them.
I’m aware of several discussions around breadcrumbs, but not that they were needed in the search results. And I can see the greater need for docs and views, which can’t get color-coded the way entities can.
The more I look at this, I think that when I see entities with the breadcrumb below that, that actually includes the entity name, that is the real part of this I have the issue with. I have never seen an implementation of any breadcrumb that includes the item itself in the breadcrumb hierarchy. If this were a tool like Wrike or Asana where your atomic entity was a “task” or something that could live anywhere (which is the case with Docs and Views), then yes 100% you’d need breadcrumbs. But entities by definition can only live in one place in Fibery. So something like leaving entities in the search results as a line item, but adding the context to Views/Docs, would still save a lot of screen real estate. We already have a snippet showing in search results for keywords from rich text boxes when you search for them, but up till now individual entities were shown as line items. Reverting back to that I think would be a great solution, but I guess I’m in the minority, so I’ll have to live with losing screen real estate!
I still think my idea a few posts up to add the breadcrumb on the right to save real estate would be worth exploring. In fact it appears the Fibery team was also thinking about the issue I’m discussing, this is from the public roadmap:
And I will add since there is a comparison to Notion here, the need in Notion is greater since you don’t have the color coding and other benefits of DB’s in Fibery, note in the Notion implementation the actual name of the entity/doc isn’t included in the breadcrumb, which is one of the issues with me with the logic around having a breadcrumb for entities. In fact the way DB’s are set up in Fibery is a big reason I’m here and not in Notion, they are vastly superior!
Sorry one more thing - since the breadcrumbs in search is particularly useful for views and docs, would you guys consider adding the public ID of views to be findable in Search Results? I realize this is technically a feature request, but it’s a small item that has come up a bunch for us, since views have public ID’s, and views (not DB’s) are the one thing in our instance that often have the exact same name. So I have this view for example:
If I type the public ID “39” in the search box, it won’t show up.
Ok @Chr1sG good catch, yes you are correct, I am mistaken. For the 2 1/2 years I have been using Fibery I have just conditioned myself to know which db’s (I still like the term “type” ) my entities are in. So when I see the db they are in, it looks redundant to me, since in the case of my Fibery instance there was never any confusion to know which db’s entities were in as I’ve been mentioning…and to your other point, I’ll respond to it directly!
So with this one, I am talking about views. That image I pasted is of a view. If I type the public ID of the view into search, the view doesn’t return…
Yep, you wrote that, and I didn’t read carefully enough, sorry.
Seems like a reasonable request - should have thought of it when the ability to search for views was added.
@antoniokov, I just now noticed that the breadcrumbs are also showing up in the collections areas where you select from just the relation in those collections. I think this is particularly redundant since by definition, the only results that can be seen are from the linked DB of the relation. You can’t see in those areas any views or docs, which are types of Fibery “items” that can benefit from having a breadcrumb about their location. So again, my point here is that with the breadcrumb, you now have 1/2 of the real estate you had before taking up by a breadcrumb that is not giving any useful information here in the collections area. Would you guys consider giving some thought to limiting the breadcrumb to the global search, where it has much better utility than in collections?
I will also note that maybe you could unify some stuff here between global search and the search in Collections, since you DO have the ability to see grayed out closed entities in the collections areas that we are discussing here. It just seems inconsistent, because it would appear to my eye, and I’m guessing many others’, that these two implementations of search are very similar since you added in breadcrumbs in both with one release, but you can’t get the grayed out closed entities into the global search, which is a highly discussed need here in the community.
I have some uses for conditional filtering. I link a materials DB to a DB with different types of products. The materials have a product type associated with them in the DB. The products contain multiple materials of a certain type. It would be very helpful to sort materials by type using ‘this product.type’. Apologizes if thats not perfectly clear, I have trouble explaining my setups sometimes.
Is it correctly understood that a Product has a single Type, and Materials also has a single Type?
Is it that when choosing which Materials to link to a Product, you want to only see Materials which fall under the same Type as the Product?
Also, you have said that you need ‘conditional filtering’ but your explanation seems to be related to sorting
Perhaps a concrete example, maybe with a couple of screenshots would help…
Here is a much simpler example of my use case for conditional filter. I made a Test Space to explain.
Currently the only relation that I see filtering in is while selecting an Estimate to link to Inspections. The desire is to be able to select Inspections from an Estimate view and only show Inspections share a common project with the Estimate.
If from the Estimate view I could add a relation filter for Inspections where Inspection.Project = Estimate.Project then I should be able to filter in the opposite direction that the current filter works. Apologies if I’ve overlooked something. I’ve been trying to work around this kind of limitation and I haven’t figured out a way yet.
Thanks for the detailed explanation!
This is a top-notch example of how to share a use case, I appreciate that a lot as a product person .
You are not overlooking anything, this filtering is indeed unavailable: the legacy hierarchical filters don’t apply to collections and the new custom filters don’t have this conditional (aka context or dynamic) logic in them yet.
Since there is no deep nested hierarchy involved, this case looks optimistic. If we can make custom context relation filters work at all, your config should work straight away.
The only caveat is that relation filters only apply to compact relation control. For collections, this means units on Views (including Table cells) as well as pinned Fields but not relation Views:
) work as you describe.
) my entities are in. So when I see the db they are in, it looks redundant to me, since in the case of my Fibery instance there was never any confusion to know which db’s entities were in as I’ve been mentioning…and to your other point, I’ll respond to it directly!
.