When I click ‘New Task’ and add the task name and hit enter, a new task gets created but with the default state ‘In Progress’ although the ‘To Do’ is the default.
If you have filter(s) applied to a view, Fibery will attempt to enforce (one of) these filters to entities created from that view.
It looks like you have an In Progress filter, so I guess this is being applied.
Hmm… That’s good to know but absolutely counterintuitive. I’d rather prefer to see the state that would be used (with an option to change it) during task creation instead of this behavior
If we didn’t apply the filter from the view, then the newly created items would disappear after creation, which people tend to find unintuitive 
Yes, I understand that. “Competitive” point of view 
What if I have both To Do and In Progress filters on? Why it still creates In Progress as the leading state?
Can you share a screenshot of your filter configuration?
I see that we have fixed a bug in the release on 28th of may (release notes)
- Filter auto apply doesn’t take default value into account
Does it help with your issue?
Hey Viktar, Nope, it still has the same old behavior - instead of creating a new task with a pre-set default status - it creates a new task with the ‘ín progress’ status.
What is the default value for your state field?
Hey! I just tested this, its indeed off.
The general bug here is:
Any time there are two or more filter conditions using the “is” condition, and are “or” grouped, it will always pick the last condition to fit the value on entity creation. No matter the default value of the field.
Why this is a bug and not expected:
If you use a “contains any of”, it will always fit the newly created entity to the first value the user picks unless the default is one of the options, in which case it will always pick the default. Example:
^ This will default to In Progress
^ This will default to Done.
(side note, the ui will sort this back when you open the menu again, but under the hood it still works)
^ This will default to To Do (since it is the default value)
Why this is relevant:
Scenario a:
Field 1 = Value 1
or
Field 1 = Value 2
or
Field 1 = Value 3
Should work the same as:
Scenario b
Field 1 is any of Value 1, Value 2, or Value 3.
It currently is not the same in the sense that:
| Scenario | If Default Exists in Options | If Default Doesnt Exist |
|---|---|---|
| Multiple “is”, “or” | Enforces last filter in list | Enforces last filter in list |
| Single “is any of” | Enforces default | Enforces first filter in list (see above) |
I hope this helps, but to be honest this configuration isn’t so tricky to test and you quickly see how things are a bit off.
Except that @myg_ge did not use ‘is any of’ 
I don’t understand what you’re saying here.
This configuration is similar to “is any of”, so it should enforce the default value, no matter the order of the filters, just like “is any of” does. No?
I just didn’t understand why you were reverse engineering the logic for an ‘is any of’ filter when it didn’t match the case that was originally mentioned
I see, the main reason is this:
But if you disagree with this premise let me know.
Well, as you pointed out, in the second case, the option chosen is governed by the order in which the filters were added, whereas in the first case it is governed by their positional order.
I am not convinced that, in the case where several ‘is’ filters exist, it would make sense that whichever was defined first be the dominant one.
And it gets even more complicated to choose the ideal behaviour when multiple filters/filter groups are present, with various combinations of AND/OR logic.
Tldr I think there is no easy answer
(but there might still be a bug to be fixed)
I think that first one or the last one is a more minor inconsistency. The main thing in this thread is about the lack of “Default” value being enforced even when it is in the options as a valid filter.
Sorry if I derailed it a little.
@myg_ge can you confirm that with the filters as you showed in the image, you are getting items created in the Done state?
That would seem inconsistent with the behaviour that Ron has described (setting aside the issue of the default state not being respected).
