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.
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.
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.
Hi @veronica 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!
Hi @Francesca. Please excuse my pre-coffee brain. I saw labels and thought attributes.
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.
