Instead of sifting through an entire Database when linking one Entity to another, pre-filter the options:
exclude done and archived work (ex. don’t suggest long-forgotten Projects for a Task)
remove irrelevant stuff (ex. stop suggesting sales reps when assigning people to a Bug)
ensure a proper process (ex. make it harder to add Stories to an already full Sprint)
It takes one Fibery guru (yourself!) to configure the relation filters — and everyone benefits from a simpler and faster UI.
Configuring filters in relations is exactly the same as on Views — check out our fresh and detailed user guide for more.
Thanks to everyone who has provided their use cases: it helped a lot to shape this functionality! Now let us know if we’ve actually delivered something useful .
In some cases, the location of an item in search results was unclear, making it difficult to pick the right one. Think of two Views with the same name in different folders.
So we’ve added breadcrumbs to search results to help you find the right thing.
Context Views embedded into rich text
It is now possible to easily insert relevant context Views into documents and rich text Fields, both by finding an existing View or by creating a new one right from text.
When searching for context views to embed, only relevant views will be shown based on the context filter. Here are the rules:
In a Document (not linked to an Entity) show context views that have some exact entity in the context filter (and hide DB-level context views)
In a Feature (or a document linked to a feature) show context views that have Feature Database or the exact entity of any Database in the context filter
Hi guys, not sure about this one. On initial read, all this is telling me is the Database/type of the entity, but I already have that info with the Database Icon.
Again I’m not sure how that’s relevant, unless I’m missing something. Databases can only live in one Space. So take your example #4060 feature “Embed Content View into Rich Text” - that has the “F” database Icon, so I already know exactly what kind of Entity it is. I don’t need that extra info.
As regards Views having their location, I also think this isn’t useful since you can create a view of anything, anywhere, (which is a great feature), so I’m never looking at where my view exists.
Finally, a big problem here is with the breadcrumbs I can now see fewer results in search. As it stood, I was happy with fact that each entity was just a line item so you could see a full list, for example when clicking “search” with no parameters so you can see a list of where you most recently visited in Fibery - that’s a great feature. But now that list is going to be cut down by quite a few so we can see the breadcrumbs.
I, and many others here active, would really like to see Seeing “Closed” Entities grayed out in Search Dialog as something of real use soon. I find this one of the few times you guys have actually come out with an enhancement that has made something worse - I’d much rather have the old way search was without the breadcrumbs.
So take your example #4060 feature “Embed Content View into Rich Text” - that has the “F” database Icon
Multiple database names can start with the same letter. Databases within different spaces can have the same name. True, that in case workspace is smaller and there are no overlaps it can be less useful.
I also think this isn’t useful since you can create a view of anything, anywhere
Those views can be named the same way, say, “Budget” and only folder name can immediately help you identify what you are looking at and what should you choose. Say, “Q1 2023”, “Q2 2023”.
The main limitation I see with the Relation Filters is the same for all the other Filters - you cannot reference field values.
E.g. in an entity view I cannot filter a Relation field show only entities “related to the same Project as this entity”. I can only filter for A SPECIFIC Project, which is useless.
I know that “Fibery magic™” is supposed to accomplish this kind of thing (by some unknown magical rules ) but it is difficult to trust – I still would like to be able to create concise filter definitions that reference the values of specific fields.
I will not be at peace until I have Formula-based filters
I think with the use of colors you can solve this. We have no same-named DB’s with the same color, since we took care to set this up since Fibery provides that excellent functionality. I’d be curious how many users actually have that many DB’s with the same name - we have none and it doesn’t seem logical to me to have that many same-named in an instance as all the suggestions around how many db’s you should have in a Fibery Instance that I’ve read in this community suggest limiting your total number of DB’s if you can.
That’s true with views, but I use search primarily to find entities, most views of relevance to me I have starred on the left nav - although not sure that’s an approach others use.
Bottom line I really miss the fact that the search results used to be nice and compact and now we’ve lost about 1/2 the real estate to the breadcrumbs. Perhaps the breadcrumbs could go on the right side, where there is a lot of free space, to keep the number of results intact as shown below?
Since the search results are (were) identifiable based on the first letter(s) of the db name, it is not unlikely that there are databases that (previously) looked the same in search.
Huge agree! I genuinely think Fibery would be a much easier sell for other departments in my company, and for new companies entirely, if you could set strict limits on relation options. Even with this update, the potential for user error is too high, which risks bad data. Constantly filtering through unrelated data is also a point of friction that wears on users.
This update is definitely a step in the right direction, but the real impact would be with formula-based filters and a way to disable the “show other” option.
the most common example for me is assignees to project tasks. I should only see people assigned to that project, not everyone in my company
Ok, I mean I have “incidents” which are orange, and “ideas” which are blue. My team associates the color (and you can add an icon like a lightbulb to ideas) and we got used to that very quickly, there is never any doubt what DB we are looking at. Again this is a credit to the basic design of DB’s that Fibery did in the first place with the color coding and ability to add an icon to the db badge.
Either way I continue to yearn for the previous list of search results where you could simple see more results. The breadcrumbs are not useful to my team. And, as I watch the feature requests carefully, I will add that I was surprised by this release as I’d not see it discussed in this community at all as something people were looking for.
Breadcrumbs were definitely discussed a few times, I’m very happy to see them. I have many docs that share the same name but at different hierarchies with the new nested docs, and also many tasks with the same name “Plan”, “Publish”, and “Invoice for Q2” that need breadcrumbs to make sense with search
We have many databases with the same name. For example: “Task” database is a part of numerous apps in our Fibery instance, as many apps we create are intended to organize and build a process around specific operations or departments in our business, and having a task database for that specific process is important, whilst still being contained within that app and process.
Creating a task in “Inventory > Task” should not necessarily go under “Team Projects > Task” or “Teammate > Task”, if we are intending to keep certain processes separate and contained. Furthermore, we have many entities that have the same name in different databases across different apps. Knowing where they are is extremely helpful.
There are times where we would accidentally select the wrong entity. Additionally, it gives better context for new users of our Fibery instance, as they may not be familiar with the color coding or badge abbreviations.
Lastly, I know you were an advocate for mobile as well. It seems this would also be the most likely design approach for mobile devices.
Overall, I’m very happy to see breadcrumbs as this was a very annoying thing for us.
Relation filters
.
Breadcrumbs in Search
Context Views embedded into rich text
Back-references in Documents
Sharing for nested Documents
Fixed Bugs
) but it is difficult to trust – I still would like to be able to create concise filter definitions that reference the values of specific fields.
