I have a table that’s a list of tasks for clients. Grouped by client.
How come that I got two groups for the same client?
And no, those aren’t two different rows — it’s the same client.
Hint: some tasks were entered manually with client being selected from a drop-down list. And the other tasks were created with a button, copying the value from the “Current client” field in a supporting table.
(I know the answer. I just wonder if you can figure what went wrong. There’s a lesson in here.)
P.S. There’s no deliberate trickery like creating and then deleting rows, hidden symbols etc. This was a result of a trivial mistake that lots of Coda users may be doing every day without even knowing it. If no one replies with the correct answer, I’ll reveal it in 24h from this post time.
Not sure if this is what you’re getting at, but it seems similar, anyway:
Manually entered tasks with client selected from drop-down list = single row.
“Current client” field returns a list of some kind (e.g., Filter(), Lookup(), etc).
Tasks created by button copy the list-of-one value to the client field, which looks identical to a single row value, but is actually a different object (list vs. row).
Hence the two groups, because they are actually two different objects, even though they don’t appear that way to users.
SOLUTION: Convert “Current client” formula from returning a list to returning a single row by appending .First(), .Last(), etc.
What a coincidence that you would post this riddle today, @Paul_Danyliuk. I’m in the middle of a huge rebuild, and just caught this. It’s proving to be quite the pain to fix, and would have created nightmares if left undiscovered until farther down the road. I brought this issue up to someone at Coda long ago, but didn’t press the matter because I was too new to properly articulate why this hidden gotcha is going to be a big problem. I could probably articulate it a little bit better now… @Krunal_Sheth
It’s all about “one” and “list of one”, which would normally look identical… until they won’t.
I don’t even have to write the tip myself — you’ve already explained it well.
Another way to avoid returning a list-of-one is to reference the row directly via @Display column value instead of Lookup()/Filter(). This will return a single row, from which you can then get a column with a single value (not a list). That’s especially if you’re just using a table as a variable container.
Another reason why I like strictly typed languages where things like this wouldn’t be possible.
[Column A] contains ONLY single values (list of one).
A button is used to populate [Column B] with the value of [Column A] (again, only single values).
It appears that simply populating single-select [Column B] with the value of multi-select [Column A] converts the column type of [Column B] to multi-select.
DISCUSSION
Ideally, perhaps the user should be prompted when a column type is going to be force converted by some action like a button, and given the option to accept forced conversion or first modify the column types to align with the desired action.
Minimally, perhaps the user should be notified about these kinds of forced type conversions, which are otherwise invisible to the user.
Thanks @Ander and @Paul_Danyliuk - I see how this is confusing - until recently we had a different UX treatment for List of items and Item but we merged them so now they visually look the same causing more confusion. I’ve logged an issue in our tracker for us to think about and see what we can do here.
What is peculiar @Ander and @Krunal_Sheth — visually ONE and LIST OF ONE look the same. Even have the same “internal JSON”. But when “inspected” through a formula, it shows that all four are different:
