One of the few true challenges I have with coda often is replicating the classic “My Work” view that is common place in more opinionated project management platforms like Asana, Linear, Jira, etc.
Meaning, that regardless of which projects/tables your tasks live, you can always just get an umbrella view of all the tasks assigned to you.
The only way I’ve solved this in Coda over the last few years is simple: one big task table. That way, you can obviously have a filtered view of the task table by owner for personalized views.
However, the consequence of that I find challenging – what if your tasks span across docs? What if you have more than one table for ad hoc meetings/projects? Once I start getting into cross-doc / sync page land, it just feels like the juice is not worth the squeeze.
Hey David!
Would’ve said “welcome to the community” but that’s just your other email account, isn’t it?
One big table of tasks is indeed the way to go but I just happen to work one something that will be able to collect multiple tables under one umbrella view — the Formula Tables pack, which I’m going to publish today or tomorrow. It will let you create tables out of formulas, which could be any formulas including those that list-combine data from multiple tables. This way it will be possible to e.g. combine the local Tasks table with the synced in tables into one single big table of tasks that you can then use for calendars, charts etc.
For syncs from various docs I planned to have a Merge table in my Sync Tables Pro pack but never got around to implementing it correctly, therefore it’s still excluded from the launched version of my pack. There are a few packs that offer merge tables from multiple cross-doc sources but frankly I never tested any of those, and I’m not sure if they offer the right level of security and access control that I was planning for mine.
Well my pack doesn’t try to inspect any tables by any names — it just renders what’s given to it. Meaning that you have to explicitly combine the values themselves and feed that to the pack.
The instructions for that use case are in this video starting at ~9:00
If it were a pack based on Coda API — and there are packs like that in the Gallery such as Merge Tables, and my Sync Tables Pro also had this in plans to support merging from multiple sync sources — indeed just the table names would be enough, and the pack developers could then auto-match based on column names or any custom mapping. However with this approach there is inevitably a delay between the moment you make your edits and the moment they can actually be retrieved through the API. Meaning, you cannot refresh immediately after you edited a value, but there can be a delay of anything between 5 seconds to 5 minutes until the value is persisted in the latest doc snapshot that’s served through the API. Also the developer had to remember to disable all caching on the pack (both formula and fetcher) otherwise you would be getting stale values from a merge table like that.
There was a question by @David_Self2 regarding ‘only need the names of the tables’ and I tried to answer it extensively, giving context about in which cases only names would be enough. One of the packs that would do this is a product not from me, yet I linked to it. Not sure why my answers got you upset; my primary goal was not to self-promote here but to offer solutions to the problem. Clearly OP knows about the right way of doing it all in a single table as they indicated in their original post.
Apologies if I misunderstood the question. Please let me know if that’s the case.
