Nathan, thanks so much for chiming in on my issue - YES you are correct!
The way I designed this application, I have a “Main Tasks” table, and then I have 3-additional Views:
The Backlog View - where any tasks w/Status considered to be “backlogged” are only shown
The Completed View where ONLY tasks marked as “Done” are shown
The All Tasks View where there is no table filtering at all so all of the tasks entered into the system can be seen
These views are on separate pages w/button links at the top of all the pages for easy navigation.
I have attached the “Table Column & Filtering” settings as I released to my team for their understanding of what’s being shown within each of the views - note: as of last Monday “Cancel” has been demoted and is now considered a “Backlog” item.
The “Eye” status was a “hack” since we were originally using an Excel spreadsheet to track our tasks and there were some Backlogged items that remained on the Tasks tab - adding that to the status of a backlogged item “brings it back” to the Main tasks table recreating that behavior…
Originally I had coded the table with “reverse logic” e.g. “do not show Backlog, Blocked, Done” etc., but upon reviewing the design with my team member, I later coded it as shown, which I considered to be cleaner and easier for anyone to understand when viewing.
If you notice I do have the additional “OR Status is blank” (highlighted) at the end of the Main tasks table, so yes, when new “Blank” tasks were added, they were properly displayed.
(I was going to remove the table’s Add Row button but I saw that she kept using it at the end of the table so I left it enabled…)
This is by design as the linked relation shows row references so clicking on it would open the row, and show it on hover.
We are thinking about how to add support for more format options such as bulleted list, numbered list etc for relation columns that could support this more natively in the future.
Hi @William_Bell, if you scroll to the bottom of the list of all statuses, there should be a blank option that you can check. If you do that to include blank in that same filter condition instead of adding a second condition just to check for blank, it may work more as expected. Can you give that a try?
By adding a blank row at the bottom there just shows “#r33” (for the new empty row) as the last selection option in the Task table’s filter list so I’m guessing that’s not what you mean.
Re: my prior picture - as far as seeing an “is Blank” option in the upper list of selectable options, that picture is showing ALL of the available options I can choose from?
I don’t see an additional “is Blank” or “Blank” option in the table’s filter list?
I even removed the “OR term” thinking perhaps “is Blank” would return as option in the “upper” list - it didn’t? The Status is using “contains any of”, as shown in my image.
The picture I provided shows ALL of the available options in that list (I used the panoramic scroll capture with my SnagIt program to capture that whole list of options as shown?)
This is why I added the additional OR term to include “is Blank” at the end?
Maybe I’m still missing what you’re suggesting, I’ll continue looking around my table options to see if I can eliminate the OR term some other way…
Hi @William_Bell, I think I see the issue – it looks like we only show ‘blank’ as an option for contains filters in single-select columns and not multi-select columns. I’m following up with the team on that.
In the meantime, I think it may work if you put the filters in the other order (with the “is blank” condition first); to do that you may need to recreate the second filter, unfortunately.
If you only need a single status per row, you can also try converting the column to single-select; I believe you may also need to re-create the filter then to have the ability to include blank in the filter.
Thanks for the details and helping us understand what behaviors are important for your scenario!
This is awesome!! What does the Option Settings > Sort do? I though it might have sorted the mutliple-select items within a cell.
Same question for Option Settings > Filter.
Thanks Nathan, yes, I also felt it was the way in which Coda’s new code was looking at the “filter tree” - it wasn’t fully parsing all the terms (2-in my case with the “OR is Blank” at the end.)
My quick solution when it started happening in our meeting was to specify for the table to add a default Status of “New” for newly created rows - which fixed the issue when the team member would click the Add New Row at the bottom of the table.
I was already pre-filling the Status column as “New” with the “New Task” button I created at the top of the page.
As a suggestion - I wish Coda had the option where you could specify a Hint Text value (grayed out text) for the data entry columns in the table - it would be great for prompting what the user needs to enter into new rows etc.
I had to place my hints at bottom of the ‘Parameters’ table (‘Application Area’ and ‘Assignee’), since placing that text at the top would cause part of it to get obscured due to the popup menu that reveals itself when the cursor is over the table as in the lower image…)
Option settings → Filter and Sort both act on the selectable options of a relation field (not what’s already selected).
In other words, they can be used to sort and/or filter what you can select in the relation field…
Depending on how your doc is set up, you could for example, only have as selectable options a list of subcategories depending on the category already selected in a row (or tasks already linked to a project, etc…)
You’ll find a little bit of info about this Here (specifically the point Option settings)
Sorry, I’m currently away so I can’t do more than this .
But I still hope it’ll help a little …
Hi Nathan, I just wanted to verify - I tried your suggestion about putting the blank term first before the others, and yes, doing it that way eliminated all the extra configuration and buttons I had put in as a fix…
This should happen automatically. We detect the previous formula and should convert to Linked Relation if we support editing. If we don’t the column will remain as a Relation column.
Do you have an example of a formula that you expect to have converted but isn’t?
Hi! This seems like a super cool feature. I was playing with it and I can not manage to make a edit in a related column from a two way sync relation table. Am i missing something, or maybe this is not possible?
Hi Ramesh, no you’re right this is happening automatically. Great!
However I see it shows a Custom Formula as the Source Column, and I still see our original formula is set as the Formula. Is there any downside to this that would motivate us to change it to the I suppose new standard way?
Hi, we currently don’t support editing values projected from a relation table directly in the column. You can open the row in detail view and view it as a sub table to support editing those values.
If the setup is working for you no need to change it. If it makes sense to enable editing on the Linked Relation for your use case, you can now toggle it on through that setting in the dialog you posted.
I have to be honest, I haven’t been visiting the Community site for a while now and thought I was hallucinating when I was looking for Lookup last week and found “relation” instead. Lol. Guess I need to spend more time here!!! Love this update, btw!
(not what’s already selected).
.
…