[Offer] Subtasks in a task

Einstein, lol :sweat_smile: nah, just a has-been developer who lost his spark for coding but coincidentally found a different niche where he could apply his skills.

As a matter of fact, I do Coda consulting for about half a year already. Super busy at the moment though — four concurrent clients at the moment and two more on hold. I already regret taking a day off today and see how tomorrow and the next week are going to be pure hell.

1 Like

P.S. Just to make things easier to understand:

  • Since “sub-topics” and “topics” are the same thing — you put them on the same table. One “kind of thing” — one table. If you had two conceptually different things (e.g. projects and tasks, having two distinct sets of properties) then you’d go with separate tables.

  • The conventional way to build a hierarchy for entries of the same kind of thing — is to specify a parent entry for each entry. The entry that has no parent entry is the one that sits on the top. In Coda this can be done by adding a Lookup column of the same table.

  • On its own, that Parent column doesn’t mean anything. It’s what you do with it then that matters. E.g., you can recursively construct the path of each item:

If(
  thisRow.[Parent item].IsBlank(),
  thisRow,
  ListCombine(thisRow.[Parent item]._Path, thisRow)
)

You can query immediate children (i.e. for each row pull rows that have this row as a parent):

thisTable.Filter(CurrentValue.[Parent item] = thisRow)

Or all descendants, based on path:

thisTable.Filter(CurrentValue != thisRow AND CurrentValue.Path.Contains(thisRow))

In my case with that tree map demo, what I’m doing is using that parent-child relation to ultimately calculate the X,Y coordinates of the nodes and lines to draw :slight_smile:

When displayed in Layout view, you can render children or descendants as a subtable. You can add a button to drill down to the sub-task via row URL (although it seems like it may have stopped working recently):

P.S. Actually in Coda this can be done the other way around as well. Instead of specifying a parent, you can add a multi-select Lookup column where you’d specify children. But I guess it’s a matter of convention to do this the other way around. First, it’s sorta traditional, since databases usually can only store one reference in a property (i.e. one parent). Second, it’s harder to mess up this way, ending up with a task belonging to multiple parents (unless that’s what you need). Third, adding tasks doesn’t require going back to the parent entry and updating the list of children there — you select the parent as you populate the child row, and so it’s harder to forget to assign it.

@Paul_Danyliuk, I had a question on this: If you have deeper hierarchy here, say 4 or 5 levels, can you create a column that will relate the descendant and ancestor all the way through the hierarchy?

So If I have something like these levels in a table for breaking down company Initiatives:

  1. Objective
  2. Initiative
  3. Project
  4. Phase

Can I set up in my Objectives rows Columns that would just show the Projects, so 2 levels down, and vice versa?

And this may be elementary, but I can probably easily group all four levels in this example to create a sort of WBS type view as discussed here?

Granted, what I’m looking for is a way to group from left to right, and not necessarily fold and view the way Krunal set up. Although if Krunal’s solution was more “natively” doable in Coda without all the formulas, I’d use it extensively!

Thanks!

Firstly, thanks for making this: already been really helpful for me as I’m new to Coda - its awesome so far!

I’ve got 2 quick questions:

  1. How do you get an embedded table to appear in the detailed view?

  2. Is it possible to nest the embedded tables? In other words, can I embed another table into the embedded sub-items table, all to be viewed in the detailed view?

Thanks massively in advance!

1 Like

@Rob_Sisson

  1. See images below.
  2. Not that I’m aware of.

1 Like

Legend, thanks!

Would be so awesome if you could nest the tables and hide or reveal them, who knows maybe ill figure a way to do this at some point,

Thanks again for your help!

1 Like

Hi has anyone had more success here?

I’m coming from a PM background in engineering and using large Primavera or MS Project schedules (not a fan but without API’s and a robust grid and a relational database the way to go for large construction or mining projects).

I’ve build estimated in excel with WBS and commodity codes so I understand how it can be done in excel, but i’m yet to see large tables work well (and not load slowly) in apps such as these. Airtale struggles with 1000’s of rows (even a small project would have 2000 rows)

So I guess my question is can Coda work for this type of use case or do we stick to docs, which I have to say are incredible and sourcing tables from larger master tables like business requirements sourced from a master req doc into a BRD or PRD works very well

Thanks in advance
Alex

hi @Alex_Whitton , the Coda Pack approach would enable us in the near future to connect DB’s like FireBase with Coda; in FireBase you put your data and you use Coda for the view and the calculations.

Coda is in this regard more the top layer, the view of your data.

Cheers, Christiaan

Thanks @Christiaan_Huizer nice, that’s an interesting solution idea

I’m going to play with the API and bring in the data to a server outside of Coda and look into it more, many thanks - had disregarded this sort of due to changes in the API but they must be minimal these days