I have the following relations: Projects > Folders > Pages.
If in the Project I create a view with child folders, Pages that don’t have a folder are not included in the view. However, I want to show all Pages.
If I create a view with Pages grouped by Folder, then I have to enable ‘Hide empty groups’ for the Folder, because the groups cannot be filtered by the current entity. If I don’t enable Hide empty groups’, then ALL folders will show, also of other Projects.
Grouping works, but:
When I want to create a new Folder as grouping item, the grouping Folder is created but does not show up because its automatically filtered out, since its empty.
So the common setup above, cannot be accomplished without an automation that forces a Page to have at least a default Folder?
and then, when you want to create a new Folder, you can first create a Page, and then create the Folder needed to contain it.
(I presume that you are creating a Folder because you plan to put something in it, no?)
Its different: The pages without folders already are present, but users cannot create a new Folder when using the view with Folders as groupings. The folder when created using the +New button in the view, is created but is immediately filtered out of visibility.
So the only woraround is to open the page, and in the Page entity add the new folder. Not a great workaround.
Or, not use Folders as groupings, but a view of Folders and have each Page automatically link to a default Folder. Not great either.
Usage of Folders in a Project is optional. Pages are by default linked to a Project. But they MAY have a Folder. If they do, they have both a parent Project and a parent Folder.
That was kinda my point.
If you’re creating a Folder and you don’t want it to disappear (due to the Hide empty groups option) then presumably you want there to be a page inside it. So why not create the Page first?
Use a board view, and use rows as groups. there that can be filtered contextually. No idea why context filters work there, but not on other groupings, but this could be a solution for now. You can set the board view items to “line” then it looks like a list.
And i personally prefer the UI of the groups like this as well, but maybe thats just personal preference.
Down side is it only allows for one level of hierarchy, but in this case I think thats okay.
Exactly, all Pages belonging to this Project irrespective of whether they live in a Folder or not.
That is the goal: Pages can ‘optionally’ use folders in the Project, next to their required Project relation.
Im also confused why when using nested databases, why it doesn’t give you the ability to use the context filter on the nested data to decide where it pulls from. When making the view as a top-level view, it shows the items with “No Folder”, but there’s no way to do that in a context, multi-relation, view.
The default and only option is: Pages from Folder from Project, no way for it to pull lower level things from lookups, other relations, or more complex relations and then show things with no folder in a “No Folder” box like it does in normal views.
Context filters are really powerful, but for some reason are only for top level hierarchies, and board view groups. Not sure why.
Can Folders only relate to a single Project? - Yes
And can Pages only relate to a single Project? - Yes
Also, do Folders act as containers for things other than Pages? - No
Hmmm. In that case, I would ask whether there is any meaning to having a relation between Project and Folder?
That may sound provocative, but hear me out.
Since a Folder exists only to house Pages, and since Pages belong to a Project, it can be inferred which Folder a Project belongs to.
In what situations is it meaningful to have an empty Folder, that is tied to a Project?
Maybe Folder is conceptually more like a Tag database, i.e. each Page may or may not get a specific Tag.
Anyway, just throwing this out there…
And the same seems to be true for the other three examples you gave.
I generally encourage people to use mvr (minimal viable relations)
Your suggestion to infer the project-folder relationship via pages and treat folders like tags doesn’t solve the issue of new folders disappearing in a pages-grouped-by-folder view with “Hide empty groups” enabled.
A direct project-folder relation allows for:
a clear, navigable hierarchy - inferring via pages confuses users.
we use structural templates, which create folders for new projects, which need a direct link for setup. Such templates use empty folders for planning, which must stay visible without pages.
ties folders to one project, preventing irrelevant folders from appearing in the view.
I guess until the grouping database in list view supports context filtering, then perhaps @RonMakesSystems’s suggestion (to use a board view) is your best bet
