Sorry if this has been covered, but I couldn’t easily find an answer.
In the example Table, I have three types of lookups that I’m pulling in - Project, Task, Product. They each have their own lookups from another table called Status. So “Project” can have the status “In Progress” just like “Task” in its own table.
So can I set up this “Status” column in this table to read each of the lookups and pull its status? I suppose I’d get a conflict if more than one of the first three columns is filled and there were conflicting Status? Is it possible to determine a priority, so say whatever the status in the first column is would be the one showing, no matter of the other columns have values?
Yes it is possible (if I correctly got your question).
Have a look at the example embedded an tell me if this is close to your use-case:
(Sorry for the bad names in the tables but the community doc is full of the same table names... )
To determine the “overall” status, you can build up a fallback chain of priorities:
Are you sure this is the best possible design? I have the feeling that it’s a mix of hierarchical (and not hierarchical) dependencies “flattened” together.
What this Table 4 should actually represent? Perhaps if you could better describe it, a better solution would come in place.
What I’m trying to do is set up a Meeting Template. Each row is an agenda item, and I’d like to be able to reference other types of rows in the Coda Doc. In this case, three types: a Project, a Task, a Client. All three have their own type of status, ie “in progress” in the case of a Project, “deal pending” in the case of a Client, etc.
Each row in the Meeting Template can refer to any of the three of these. But since I don’t want to have a column for each, and then a column for each of their respective status, I was trying to have only one column for the status, which would get filled in depending on which of the three types of other data rows are discussed.
I hope that makes sense!
Incidentally, this would be much easier if I could just reference any row in the entirety of the Coda Doc in these agenda item rows in the Meeting Template. I’ve been requesting this across the community as you may have seen! In an ideal world, I’d simply link any row via the @mention, then pull in whatever value was in its “status” column. There would be no need for these three columns, which in effect are “reserved” so I can have the option to refer to all three types of rows, if need be. But in reality, two of the columns will always be empty, which I think is inefficient.
If you have any better ideas on how to solve this, I’m all ears!
I took some time to figure out what you wish.
Basically, (I think) you need a polymorphic column that could act like a Lookup (see Edit below).
Disclaimer:
I would not suggest it as a solution, but let’s see if it’s a nice starting point to play around with.
Why?
Well, “dynamic lookup” is strongly coupled with tables structures.
I used a common Status (in fact, not strictly necessary) in order to mitigate it a bit.
Essentially, you’re moving the “multiple columns” in the fallback chain logic. It’s more hidden, but still…
Please, have a look at the modified example and tell me if it’s closer:
Let me know if this meets your needs.
Cheers!
Edit:
If this (Table Extensions) would be taken into consideration, this solution would become straightforward by design…
Hi again @Federico_Stefanato. Many thanks for this! I am somewhat aware of the concept of Polymorphic, and read your post at Table Extensions , which I think also is something I could use. Not sure if this is entirely what you were trying to accomplish there, but I have many task types:
Task
Bug
Communication
Research
etc. and for now I am simply using a column “type” to distinguish them. This is in fact one of the reasons I have this need, but it sounds like your Table Extensions solution would kind of “build in” that type right into the row itself, which would be great. Are you familiar with Jira, and is this sort of a solution to allow for an “issue type” equivalent in Coda?
I will play with what you proposed and get back to you with some feedback, thanks again!
I was not really aware that a lookup can pull from many tables. Sorry for the ignorance here, but it appears that is possible? If so, that would greatly change my approach to my entire doc!
However, this also raises a few more questions:
I see I can indicate the option to add a row in this column:
Do you know if that will really work? I tried it, but I don’t seem to be able to actually enter any text in the column to complete a row. Assuming this is doable, where would the new row go since I am accessing multiple tables here? One thing I want to do is both reference existing items, hence this lookup, and also add a new item that comes up in-meeting to the Table in question - ie, we think of a new task, so I’d like to add that task to the Task Table, and trace that it originated in this meeting.
Hi @ABp,
sorry for being so unresponsive, but I’m quite busy these days…
So here we go!
Yes, I am.
This is why they are in fact Issues and they all have (possess) a feature: type.
This allow you to deal with many different issues.
In our example, a better design would go in the same direction: build up a Issue table that have a type column (populated with Task, Bug, Communication, Research, … you name it).
The side effect of this approach is that many columns of Issues table would be specific to each type, therefore it would contain the whole set of types features.
This also would explain your second question:
Just because this column is not a genuine lookup column (rather a select list), Coda could not infer what entry should be added.
In a real lookup condition, you can in fact add new rows in the drop-down, if you allow it.
I hope this helps.
Please, let me know if I clarified your doubts.
@Federico_Stefanato, really appreciate your time helping me. No issue at all with any delay. I continue to be impressed with you and some other Power Makers’ amazing grasp of Coda functions. I in fact asked support about your solution, and I heard back that using Polymorphic isn’t recommended as it’s sort of a “hidden” part of formulas that is untested!
There’s a lot of manual work I’d need to do to set this up, and maintenance to make sure this set up can grow for my needs. I don’t mean to sound like a broken record, but this type of solution is something that has driven me, for the time being, to move off Coda. I’ve been back and forth with Coda for many months so I may return! Your solution is excellent, but I’m not a developer, and I think I’d need to bring one of mine in to keep this maintained and also integrate it into the rest of my doc.
Thank you again for the repeated help here in the community, and I’m sure I will speak to you again shortly!
