Table filters behaving strange

1

Hey all,
I don’t want to call this a bug, but I’ve spend the best part of 2 days building a proof of concept doc a couple of different ways, only to come across the same extremely odd behaviour.

What I have not been able to do is create a super simple repro - I’m guessing the particular use case I’m trying to create might mean what is seen might not be that usual.

Essentially, I have a table display, and a column with the same table filtered and displayed inside. But I don’t think thats what is causing the issue.

I’m adding rows to the table with a button - and this is where things fall down.

Even though I have a formula on my canvas that calculates the filter one way, this is not matched in the filter itself UNTIL a user clicks outside of the display. Then it “rights” itself. It should always filter down to a single row to display - the filter contains a .first() for safety, even though there’s (as far as I know) no way for the formula to return more than one row (as it refers to a select column that is restricted to a single selection.

I have made a gif showing the issue.

Strange_Filter_Behaviour

I’m really well and truly flummoxed by it. I’ve tried all sorts of things… converting to text for the comparisons.

I have seen some issues in the past with row ID’s, but I’m using

Split(thisRow + “”, “/”).Last()

to ensure that the row ID I need is created immediately upon the row being created.

I think I’ve seen things in the past that are possibly related to this, but I cannot for the life of me find anything in the forum now. Any help much appreciated. Happy to provide more info if its required - just shout what you’d like to know.

2

The formula I’m using for the filter is

thisRow=helper.filter(Name=user()).Viewing_Control.First()

helper is a table with one row per user. Viewing_Control is a formula to select the correct note to view - but its not complicated. Its just looking for either the latest note (last note) OR a stamped value in a different column (which in this case happens to also be the last note since there was one just made with new note. This control isn’t actually doing much at the moment - but it was when I earlier had tag filtering working - except then this bug got in the way and I slowly started removing parts of the doc / turning things off.

Eventually I would like the view to change when the orange edit icons are clicked. At the moment, it opens the correct row - but in a modal. This is the ONLY way to currently get it to work without this bug. But of course, then it closes back to the view as it was before you edited a different line.

I can also open the row to edit straight away in a model from the add note button, but this defeats the purpose of this particular interface. I’m trying to get things to work for my producer with the least amount of clicks possible, and in the most “app” like way.

Right now, I fear the only way I can make this work is by not displaying the note canvas at all in the normal display - and having it just be a table of the available rows to select. Then you select a row to view it, and need to hit close to close it. It makes it super hard to navigate all through the notes - where as I thought I had a really interesting way of presenting notes. Alas.

EDIT : Confirming that I just changed the “edit” button to basically just change the row that the filter should see. And that value changes in the canvas equation, but does not change the filter until you click outside the display again.

Here’s another gif to confirm.

Confirm_Filter_Issue

3

Could you share a copy of this doc, or a minimal reproduction if the doc includes private data?

4

Yeah. Its just a prototype - it’s a little messy, thus thinking gifs might be better this time round. I’ll try clean up the important bits to make it easier to look through. Later this morning.

5

So a super important piece of information.
Our producer has just showed me that this same issue is effecting our old system - which has worked perfectly for the last few years, but is now driving her crazy. She just took me through it - and the filters are NOT updating correctly.

She said this has been a while - months, but not 6 months. She just assumed I’d stuffed it up - but no changes were made my end. This means that a change on codas side has meant what I am doing no longer works. (Our old system also uses helper tables - one user per row - which I have a suspicion is where the issue may lie.)

The mystery deepens.

I’ll clean this prototype and share shortly. I’d love to find out the solution…
@Paul_Danyliuk have any of your docs that used user tables stopped working correctly? (Specifically, the filtering of detail views?)

6

Ok - so I’ve managed to create a relatively simple doc for you all to play with which shows the problem.

As far as I can see, there are two different ways you can cause the filter view to behave incorrectly and NOT show the correct filter row in the display view.

There are two pages. The first is the tables - and you’ll have to fill in your own details in the helper table.

The second is the UI, where the fun happens.

There are two separate ways that you can bring on the filter problem.
Method 1.

  1. Select a new project in the top line user menu
  2. Hit new note in the display view underneath
  3. Notice that the note being displayed is NOT the note just created, even though that note is being filtered for in the filter formula (there’s a nice double check in the user_helper menu - the note_viewing column is what the filter is meant to be filtering. So how come it shows a different note?
  4. Click outside the display view, and the filter will now show the correct row.

Method 2.

  1. On ANY project (you don’t need to first select a new project like method 1) hit the edit button on any note from the current project.
  2. The helper shows the correct value that the filter should be using, but the displayed row does NOT update.
  3. Click outside the display view, and the filter will now show the correct row.
7

@Nick_HE does that document help explain the issue?

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.