Is your feature request related to a problem? Please describe.
When a view has a filter with an "is equal" condition on a column that is hidden in that view, creating a new row from within that view does not pre-fill the hidden column with the filter's value. As a result, the newly created row doesn't match the filter condition and immediately disappears from the view, even though the user just created it from there.
Example:
View "Open tickets" filters on Status = Open, but the Status column is hidden in this view.
User clicks "Create row" from the "Open tickets" view.
The new row is created with Status empty (or a different default), so it doesn't satisfy Status = Open.
The row vanishes from the view immediately after creation, which is confusing since the user has no visual feedback about why.
Describe the solution you'd like
When a row is created from a view that has one or more "equals" filters on hidden (or even visible) columns, the value(s) used in those filters should be applied as default value(s) for the corresponding column(s) on the new row. This way, a row created from a filtered view actually satisfies the filter and remains visible, matching user expectation ("I created this row here, it should stay here").
Scope suggestion: this should probably apply specifically to is-equal-type conditions (and similar unambiguous single-value operators), since it's not possible to auto-derive a sensible default for ranges, "contains", "is-empty", etc.
Describe alternatives you've considered
Showing a warning/toast when creating a row from a view that has a filter on a hidden column, explaining that the row may not appear unless required fields are set.
Making it clear in the row creation form that the row might not respect the current view filters, so the user manually sets the value.
Both alternatives are "explain the confusing behavior" rather than "fix the confusing behavior," so the auto-default approach is preferable if feasible.
Additional context
This ties into hidden-column behavior more broadly — since the column isn't shown, there's no way for the user to even notice or set the value manually at creation time. Auto-populating from the active filter seems like the least surprising fix.
Is your feature request related to a problem? Please describe.
When a view has a filter with an "is equal" condition on a column that is hidden in that view, creating a new row from within that view does not pre-fill the hidden column with the filter's value. As a result, the newly created row doesn't match the filter condition and immediately disappears from the view, even though the user just created it from there.
Example:
View "Open tickets" filters on Status = Open, but the Status column is hidden in this view.
User clicks "Create row" from the "Open tickets" view.
The new row is created with Status empty (or a different default), so it doesn't satisfy Status = Open.
The row vanishes from the view immediately after creation, which is confusing since the user has no visual feedback about why.
Describe the solution you'd like
When a row is created from a view that has one or more "equals" filters on hidden (or even visible) columns, the value(s) used in those filters should be applied as default value(s) for the corresponding column(s) on the new row. This way, a row created from a filtered view actually satisfies the filter and remains visible, matching user expectation ("I created this row here, it should stay here").
Scope suggestion: this should probably apply specifically to is-equal-type conditions (and similar unambiguous single-value operators), since it's not possible to auto-derive a sensible default for ranges, "contains", "is-empty", etc.
Describe alternatives you've considered
Showing a warning/toast when creating a row from a view that has a filter on a hidden column, explaining that the row may not appear unless required fields are set.
Making it clear in the row creation form that the row might not respect the current view filters, so the user manually sets the value.
Both alternatives are "explain the confusing behavior" rather than "fix the confusing behavior," so the auto-default approach is preferable if feasible.
Additional context
This ties into hidden-column behavior more broadly — since the column isn't shown, there's no way for the user to even notice or set the value manually at creation time. Auto-populating from the active filter seems like the least surprising fix.