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.
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).