If I understand correctly what you are trying to do, you should refer to the views filter(s) if you want to get the same rows that the view has.
If you want the same columns, you would use a layout associated with the view.
I later night answer, hope it makes sense.
Thanks for the answer - So the view filter won’t work for this because the view filter is filtering the rows of that view of the given table (in this case the ‘tasks’ table).
What I am needing to do is filter the ‘sub-tasks’ table (which displays rows from that ‘sub-task’ table in the sub-task field in the ‘task’ table) formulaically in a relation field depending on which view of the ‘tasks’ table is in question.
So I was hopeful with the “ThisTable” and “IsFromTable” functions, but they only work with the master versions of a table and do not recognize views thereof.
So I guess in summary, I’m looking for a way to formulaically recognize the view of a table and then take an action based on that.
Unfortunately I struggle to follow the abstract that you are explaining.
Is it possible to share a doc with an outline of what you are trying to do in business terms?
What is the formula supposed to achieve?
Really appreciate your input, thanks.
Here’s a quick video explaining what I’m trying to do,
Thanks again for looking into this.
Thanks for the explanation, that helped a lot to understand. And that is some next level filtering you have there.
I am not aware of any formula that will allow you to get metadata about a table or view.
But from your explanation, it sounded as if these new views that are getting created, would be user specific. If they are, then you could put that filter formula inside a switchIf(user=xxx, ).
HOWEVER, this will influence all tables for the user in the document, not just the specific view. But this might make things easier, you do not have to have additional views, just a user-specific filter formula for the sub-tasks.
The however also applies to any other selection you use - I tried using a select control on the page where the view is, but that is going to apply to all views. The only solution would come when/ if Coda adds a this Page/ thisView to thisTable and thisRow.
Thank you for reviewing that, and I appreciate your out the box thinking of switchif’ing based on a user, although it wouldn’t really do the job here as the same user would want to see that field (sub-tasks) displaying differently based on the view they’re looking at.
I am kinda baffled as to why there isn’t a ‘ispage’ or ‘isview/table’ function as I can imagine quite a few use cases for it and I can’t immediately see why it would be computationally onerous (not that I’m a dev!)…then again maybe most people aren’t creating such generalized docs which then require detailed personalization (but for tasks that seems like a use case most would want, i.e. never siloing your work management).
It’s a pleasure!
There is quite a bit of demand for something like thisPage.
But a lot of people are asking for a lot of things…