Skip to content

Rows created from a filtered view disappear when the filter targets a hidden column #2992

Description

@Aveyron-RetD

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    0. Needs triagePending approval or rejection. This issue is pending approval.enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions