I wanted to build myself a personal task management system on Coda and I got stuck on the subtask implementation. I’m currently using another outlining tool and I do not want to define a project in advance - I would just want to enter some details under a task, each of which could be completed.
I’m still starting my work on Coda, so sorry if I have missed something.
If you want to use one table, you could group your main tasks and have sub tasks to those groups.
With the new layout feature, you could also create a detail view and add a sub table to each row entries but you would need two tables.
The best way to think this one, is that your main task should be a lookup that could be assigned to each sub tasks and in return in your detail view, one column should be a look up too, to show on the sub table.
Thanks! That sounds useful. Let me explore this!
I am trying to do the same thing and was going to use a button in the row to create the subtask. When the button is clicked it would incrementally increase the value of the “index” column. These indexs would then be used to establish the relationship between the parent task and child task. I am having trouble getting the formula for the button to work.
I would be very interested to see some screenshots of how you’re doing this.
I’m not quite following your written description.
@Ander for which solution do you need screenshots?
The first one is easy. Create a table with one column called tasks another called subtasks.
At the header of task, right click and click on group column to left.
This way you’ll have tasks as groups and subtasks as rows.
@tomavatars Your second solution.
Here’s one interpretation of @tomavatars’s second solution.
Hey guys, I was trying to set up an easy way to create Subtasks while “pounding out” items in a table that are generally work items for my team. They could be turned into individual tasks, even whole projects. These are essentially ideas.
What I’d like to do is to let the author add in the top level items, then quickly in a row add in some subitems, with hopefully a good deal of hierarchy available, say 4 levels down.
@Ander in your screenshot, I notice you have the ability for subtasks to belong to multiple parents, that’s excellent as I’m looking for that. Could you tell me if your model allows for quick addition of subtasks while typing in the higher level doc? I’d like to avoid having to add in the subtasks separately, then come back and link them.
Thanks for any advice you have!
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 ), so it could probably use some tweaking:
@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
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!
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.
@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!