[Offer] Subtasks in a task

@ABp

This is probably not 100% of the functionality that you want, but perhaps you can use it as a component in your larger build-out. Note that there are two sections, illustrating two approaches. I use the “free” approach heavily. I’ve never used the “constrained” approach in production (though I may now start :sunglasses:), so it could probably use some tweaking:

1 Like

@Ander many thanks this is really useful! I didn’t know how I could get this level of speed in Coda, although I was pretty sure it was possible with the right set-up.

I also was able to easily reproduce @tomavatars “first” solution of grouping the first column for the main tasks, then having subtasks in the 2nd, simple enough for a Coda novice such as myself. I did want to ask if either of you know if I can continue to do this to some unlimited level of hierarchy, say the 4 I was thinking of in my last comment?

Many thanks again this is really useful and is a big piece for the potential of realizing my plans with Coda

@ABp

Sample doc illustrating the 4 levels?

I’ve also been able to reproduce this with a small table,
However as soon as I get past around 10 entries in the “sub-tasks” section it no longer allows me to set the detailed view column to a table.

Hi @Ander, as always thank you for taking time to help me.

To clarify, were you looking for me to provide a sample of a “4 level” hierarchy that could be done with the methods we are discussing here? I am actually still working in this so I haven’t gotten that far yet. What I’m hoping to do is to be able to have several levels of hierarchy I can quickly add to, without going to the full extent of Krunal’s sample here "Serious" Project Management in Coda? (Work Breakdown Structures) as there are some advanced elements that I’d like to avoid at this juncture.

To give you some background into my situation, I am in a small software development start-up, and I am trying to lay a PM foundation for my team with Coda. If I can get some of the basics we need established, I will be bringing in a db guy on my team to help build out our set up with some more advanced functions as again, I am very novice when it comes to spreadsheets/db’s.

Thanks again for all the help!

@ABp

Yes, when you get that far, basically just a sample doc using real-world concepts that illustrate your use case for 4 levels of hierarchy.

@Joshua_Upton could you please tell me more about what you are experiencing - we dont limit table/grid based on # of entries - so if you are seeing that, it would be a bug, I would appreciate if you could reach out to our support via in product chat

I came back to the doc in question a few days later and it worked fine.
I agree it must have just been a bug.

Hey @tomavatars, I know it’s been a while but I am working on a solution where I want to try to keep the hierarchical items in one table, this is your “first” solution from this thread.

My goal with the doc is to create an outline arrangement where I could do this:

I’d like to have a “top” level in the table that represents a topic discussed in a meeting.

As the meeting moves along, it could turn out that the participants bring up additional points that are sub topics to this original topic. However, I’d like to treat these subtopics as their own “topics” in the same table, but have them be considered “sub topics” of the main topic. Some “main topics” may contain no “sub topics”, so they would also exist in the table, with no sub items.

I have grouped the columns for the one table as you explained, but I’m wondering if I can now open the “parent” topic, and display in a subtable embedded the list of sub topics? I know I can do this if the subitems are in two tables as you’ve explained, but I would like all these topics to be in one table.

One thing I cannot figure out here is how to “pop open” the parents when they are grouped like this. Coda does not give me the option. In using your 2nd example, when the parents are in a 2nd table, I get this option.

Generally I have been playing with subitems that are both in one table, and in two tables, and I seem to be running across quite a bit of differing capability in terms of displaying sub items, adding inline new items, etc. depending on whether there is one, or two tables. I’d be grateful if you, or another expert in the community, could explain in some detail these differences. Another goal of mine is to try to avoid setting up too many tables, as I am using a lot of relations in my doc, and every new table forces me into new lookup columns if I want to be able to relate items in say 5 rows with a different group of 5 rows.

I appreciate any insight you can provide, and if this is unclear, I will be glad to elaborate further!

Just in case anyone still wonders. This example contains a doc where any level of task/subtask nesting is possible (and as an addition, it’s visualized as a tree map):

The idea is to specify a parent for each task. Feel free to use the above document as a template (copy the DB Items table and delete the columns responsible for tree map node position calculations).

Here’s how to limit the selection of parents to only valid ones, so that you don’t accidentally make a parent of a task that is already a sub-task of this task:

This is already implemented in the above doc.

1 Like

@Paul_Danyliuk, many thanks! At times I feel like you are like Einstein and this is just second nature to you, but I am going to need a bit to make sure I understand what you’ve explained, but glossing over it makes a lot of sense.

Really appreciate having the community master weigh in on a question I had. I have been gearing up to possibly get a quote from you once you start offer official consulting services by the way :)!

Thanks again Paul!

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