Pre population of attributes already filtered by view (table)


in a table view with a filter like “$label is $this” when you create a new row (element), the $label is prepopulated with the value $this. This is handy because if you are writing here you probably want to add something related to $this.

But if your filter is “$label is not $this”, new rows (elements) shouldn’t be propulated with $this as, for the same reason as before, you’re probably creating something in this view that has nothing to do with what you excluded from here.

As a matter of fact, as soon as you create the row which is already marked with the excluded attribute, infinity correctly alerts that this line will be hidden as soon as editing will be finished (if the categorization won’t be changed).

I believe that new lines of a filtered view should simply be shown clean, without any pre-compilation.

1 Like

Hey @Francesca,

Is it okay if you maybe made a video of this situation? I think it might help me understand the issue more clear :slight_smile:

Thanks in advance!

Sure! Check this:
Hope can be clearer!

In the second part of the video, I think I should have a clean new row instead of a prepopulated one.

Await your opinion!


Hey @Francesca,

Thank you very much for taking the time to create and send us the video.

We got it. It’s a bug, and our CTO is already on it :slight_smile:

It should be fixed by next week.

1 Like

Hi @coa,

I saw you guys fixed this little bug in the table view, but I noticed that is happening in Kanban too. The behaviour is the same: I have this view filtered to exclude a specific tag, but if I add a new task in a Kabna Col I get the task categorized with the filtered tag too.

1 Like

Hey @Francesca,

Thank you very much for adding this.

I’ll make sure to check it with the devs and fix it ASAP. :slight_smile:

Hey @Francesca,

I can’t seem to reproduce this problem…

Can you check again and if there’s still the bug present, can you maybe send us a quick video? Sorry for all the trouble! :slight_smile:

Thanks in advance.

Actually, I saw it was not entirely fixed the first problem I reported.
I got confused because in my filter to exclude some labels I’m exluding more than one label. In this case, when I add a new row the filtered labels get showed for some seconds and then are deleted. This is correct. If you are excluding only one label, then the problem is still happening.

Let me know if you need the video, but it won’t be very different from the first one I sent you. I can just add a case with a kanban view, but my steps to show the error would be the same you saw. Let me know.

1 Like

Oh shoot. That’s strange.

I’ve tried clicking on the video you’ve previously shared, but it seems like WeTransfer link expired. :confused:

If you have time to make a new one - that’d be great. If not, I’ll make sure to dig into my ‘Downloads’ or ‘Recycle Bin’ :slight_smile:

No problem, I found it in my recycle bin! I’m sending a new link to you. Let me know if it’s enought to understand.

1 Like

Still seeing the problem. If this is the same thing that I’m seeing on my end, here is a gif of my experience. @coa

@Francesca Nice work finding this. I only noticed this today when I forgot I had a filter on.


Hi @veronica :slight_smile: Mine was related to tags, but behaviour is the same.

In my experience, it’s pretty usefull that each task created in a “positive filter” (tag is $this) gets immediately tagged with this. As I said, if I’m writing in my filtered board, I’m assuming I’m creating a compatible task. This applies a little less in the case of a description that requires a more in-depth contribution. It could be a valid help for pretag in any case. Personally I can consider it a useful feature.

The real bug is imho if you have a negative filter (tag or description is not), then in that case I definitely don’t expect to see a pre-writing with that parameter.

Thinking together always leads to greater analysis. I feel very part of Infinity!

1 Like

Hi @Francesca. Please excuse my pre-coffee brain. I saw labels and thought attributes. :slight_smile:
I can see how it could be useful to pre-populate based on a filter, but there might only be a use-case for that when filtering “is” for labels.

However, when I think of filters, I view them as non-destructive and they don’t affect how other functions work. I make a new row and I personally don’t want it to pre-select or fill anything in. Either way, you are correct in that an “is not” filter should not populate the field with the negated tag.

Glad that you feel a part of the community! Feedback is so important.

1 Like