Grid and List view both fail to display INDIRECTLY related entities in a Smart Folder, which are correctly displayed by a Table view.
This is the
Page Workflow relation in
Views are defined inside this Smart Folder:
Table views can find the indirectly-related
Page Workflow entities (related to Page, which is related to Project):
But Grid view cannot:
Nor can List view:
What does the filter setting show?
Smart Folder filters:
Note that Grid view can display (directly-related)
Pages, but not indirectly-related
I meant the view filters (= context filters)
If the views are in a smart folder, they will have context filters automatically applied. Click the funnel for each view and see what is shown.
Oh, yeah, this is messed up – here is where the Table is getting its records from:
This really should be
Page Workflows via Pages from (Project). As should the Grid and List as well.
The Grid view that finds nothing:
Same with the List view:
I believe I complained before about this before, loooong ago. It makes no sense for this path selection to be automatic with no possibility of manual override, especially if it can’t get it right
Even if it could get it “right”, we might still want to use a different relation path.
Click on the white text part and you can change the path to whichever you prefer (subject to certain constraints - see here)
OK, that’s a step forward, but not much good if you have over a thousand of options that you can’t read:
If we could see the full text of these lines, we might have a chance here
I complained about this problem before - Smart Folder View Filter is beyond unworkable
Well, the number of options is determined by the number of possible ‘routes’ between the two dbs, and in a highly connected workspace this can be many.
Based on what you wrote earlier, you would in principle be looking for ‘Page Workflows via Pages from Projects’, so the colours should be able to clue you in.
However, I think you might not find the route you want, because of the constraints mentioned in the page I linked to previously.
It would be helpful if these routes routes were sorted by complexity (most-direct routes first).
In a vast majority of cases, one of the most-direct routes is likely what someone is looking for.
AFAIK that is the intended behaviour.
In this situation:
Meeting Notes has-a
Client (to-one relation)
It is simple to associate each
Task with its
Meeting Notes via the
But apparently not the other way around – i.e. in a
Meeting Notes entity, in an embedded Table of
Tasks, I want the context filter to produce the collection of all
Tasks related to the common
I was expecting the Fibery context filter to include the simple, direct option: “Tasks from Client”, because there is a common
Client – but that option is not in the list In fact, the context filter does not offer any options that use the
Client field .
Based on what you have said, the relationship path between Meeting and Task would seem to be
Task ← Client → Meeting which is not be supported because of the constraints discussed earlier.
However, if I have understood your situation correctly, you could create a lookup in the Task db to get the Meetings from the Client. In this case, you would have an option to context filter Tasks as follows:
That’s because there would now be a direct path
Task → Meetings