By George I think I’ve got it. I played with Sunny’s detailed instructions. Peter G. and Carl Holmes both contacted me back channel and helped me achieve full understanding of Sunny’s responses. I’ve written this up for my benefit and the benefit of anybody else who needs, as I do, to be led by the nose. 
.
Providing canned filters AND ad hoc filters
2022-04-08
In my Tasks database (as in many other projects I do) I wanted to be able to provide canned filters for users to pick. In Tasks, it makes sense to have a canned filter for tasks whose date = today, and to allow the user to click on a button to see those tasks quickly. And once I’ve done that, it makes sense to provide a couple more quick filters: to show overdue tasks (date < today), upcoming tasks, ALL tasks regardless of date, and perhaps all tasks that have been completed.
Sunny in the Knack Forums threw me the big clues about how to do this but I didn’t follow him fully. Peter Greulich offered to walk me through it. And Carl Holmes contacted me back channel to provide excellent links to videos (here and here) showing these techniques. I owe my understanding entirely to them. I did not figure this out on my own. I’m writing down the steps below to review what I’ve learned from them and to help me remember it later.
The basic idea is pretty simple: You create multiple pages, each with an instance of the same data table but with different default filters. You then create a menu to jump between the views.
Canned filters for Projects: Active, Inactive
I said above that I first faced this problem in my tasks database, in the Tasks table. In this recipe below I’m switching to the case of making canned filters for Project records. It’s the same concept. This assumes that I’ve started with a page that has a table view for Project records on it already.
- Go to Pages area of the builder .
- Create a blank new page. Can be public or login. I’m going to make it a login page. Name it Projects Nav. Knack will automatically create TWO pages: One called “Projects Nav” (the one I’m about to work with) and a parent to that page called Projects Nav Login. Going to ignore the login page.
- You’re now asked to add a view. Under Static Views, drag a blank menu view to the page. The menu view initially says “This menu is empty” and invites you to put something into it.
- Before continuing with the menu object, at the bottom of the Build Menu panel, check both “Tabbed Menu” and “Auto Link”.
- Now, back at the top of the Build Menu panel, click “Link to a New Page”. Give the page a name. I’m naming mine “Active”. Click “Add Menu” to save the menu object, then save changes to the page.
- Click on the menu view again, and add another item. I’m calling my second item “Inactive”. Submit, save changes to the page.
- You should now be looking at a little hierarchy of pages. In my case, the hierarchy looks like this: Project Records Login < Project Records < first page named “Active”, second page named “Inactive”.
- Go to the original Projects table view page (the one I said at the start I assume you already have created) and click on the table view there that you want to use as a model for the table view in your new pages.
- Hover above the table’s ellipsis “…” menu and select Copy. Pick a page to copy the table to. In my case, the first time I did this, I copied the page to the Active page I created in step 5 above. Confirm what you’ve done and click Continue. Then click Go to New Page.
- You’re now looking at the first of your “menu-controlled pages”. Click on the table that was copied to this page, and then on Source in the Edit Table panel on the left.
- In Edit Table/Source panel, click link “Add rules to filter records”. Define the filter that you want to control which records appear in this table by default. I picked Status = “Active”. Save changes.
- Click on the table view once again, and this time in the panel on the left go to Settings. Under Filter Options, set the filter options you want users to be able to have. I set my page up so users can define their own filters. Remember that any filter created by the user this way will be filtering the set of records you already defined in the previous step. In other words, if this table is permitted only to show active projects, if users filter projects that have been assigned to (say) Larry, the record set returned will show only Larry’s active projects.
- You can now click on the table you’re looking at and repeat steps 9–12 above, making appropriate changes to the default table filter. In my case, for my second page, I made the default filter show project records whose status = inactive.
And that’s basically it. The steps above will create multiple pages, each containing a view of your table that is identical initially (because the views were created by being copied from a model) and each of which displays a record set limited by a default record-source filter.
You must now keep in mind that you’re actually dealing with multiple distinct instances of the table view. If you want your table to appear unchanging when user clicks on one of the filter tabs or another, and if you make a change to one of the instances of the table, you’ll have to make the same change to the other views. On the other hand, if you want to have different views showing different columns, you can do that.
You may have to do some clean up now to handle creation of new records and other workflow issues.
Explaining the trick
The “trick” here — what made this seem like magic to me at first — really occurs in step 4 above, where you check both of the options at the bottom of the setup panel: to create a tabbed menu, and to auto-link to the first page in the menu. The auto link means that the user never sees that page where the menu was created, which is otherwise a blank page. A secondary mystery that I don’t fully understand lies in the fact that this menu page passes the menu to the two “child” pages linked to from the menu.
Quite clever and fairly neat. Many thanks to my many friends here.
