I appreciate the help, but that didn’t seem to do the trick, although maybe I didn’t articulate my struggles well enough.
My issue isn’t about getting the context filter to show the hierarchy I want, but that it’s not handling the filtering of the entities that I am expecting it to have.
When looking at a list view within a Sprint entity, I only want to see Iterations that are linked to the Sprint, but I want those Iterations to be visually nested underneath a Client → Program → Release → Iteration hierarchy.
I’ve been assuming that with the power of Context Views, this would be possible, but no matter how I seem to set things up, all Iterations that are linked to the Release are getting displayed, including ones that are not linked to the Sprint.
So what is happening is this:
Imagine that the relationship is that of a tree:
Client = trunk
Program = branch
Release = twig
Iteration = leaf
Sprint = insect visiting multiple leaves (!)
Your context view is limited to only the tree trunk (Client) that the insect (Sprint) is on, and for that trunk, show all its branches, twigs and leaves irrespective of whether the insect has visited them all.
The context filter does not just show the trunk + only its branches with twigs that have leaves the insect has visited + only the twigs that have leaves the insect has visited + only the leaves the insect has visited.
I already had lookup fields equivalent to what @Matt_Blais had mentioned, so displaying the levels in my screenshot was never the issue. Contextually filtering the entities that are actually displayed in each of those levels is what I’m trying to solve, does that make sense?
The context filter seems to only filter out the top level, when I was expecting it to filter out all levels.
I think any of these 3 things would solve my issue:
1. If the context filter was truly applied to “All Databases” like the UI implies it is.
I think you are right to point out that displaying the context filter (which only applies to the root level) when the ‘All databases’ section is highlighted is misleading, however, it does say that it is filtering for ‘Clients via …’ not generically ‘Entities via …’.
You are actually on to something that we have had in our backlog, which is to implement context filters as merely a specific case of ‘dynamic filters’ in the greater context of flexible filters including support for formulas.
Unfortunately, we don’t know when we’ll get to it, and no guarantees that the first version will support multiple layers of querying (which I kinda think your case would need if lookups are to be avoided).
Yeah, if the context filter was only displayed on the root database and not in the “All Databases” section I wouldn’t have assumed it would be applied globally. When you have a lot of databases and relationships, that filtering dropdown gets absolutely insanely full and is basically unusable (half of the options don’t even fit on the screen) so I kind of gave up trying to understand it.
I don’t love having a lot of lookups that make entities look messy/unpure, but that’s just reality of Fibery without more advanced filtering options. If that’s what the first version of more dynamic filters would require, I’d have no problem doing it! Is there a specific feature request somewhere for this I could put a vote on?
Looking at entities in context with other entities is very important to us and probably the biggest reason I’m trying to migrate away from ClickUp and into Fibery. That said, I feel the table view is the least flexible and contextual way to look at our data, which is why list view is so important.
Once the “grouping by fields” feature is done (sounds like it’s a Q1 2024 thing) it will make all the views (especially table view) infinitely more flexible and mitigate our need to have everything displayed in a hierarchal fashion, so I’m really looking forward to that!
This way, the context filtering doesn’t have to traverse up the full tree (and guess which field to filter against), but is available as a value for the creator to strategically apply to particular fields at particular levels just like normal filters.
This is something I’m struggling with and would greatly benefit from as well. It is also something that I don’t think formulas in filters are going to address since they need the view context rather than working on any of the entity data.
That would be a valid solution too! I’m not sure how hard these things are for the Fibery to implement but I can tell you that I just spent almost a full day building a crazy amount of ugly formulas and one-off administrative fields across all my databases to be able to solve this with a single filter on the “All Databases” level. It’s still a manual filter that needs to be changed every sprint until the end of time, but it’s better than nothing.