Rows created from a filtered view disappear when the filter targets a hidden column
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 214
- Forks
- 52
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 82
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named in the issue. Start by tracing the row-creation flow and the handling of view filters, then inspect how equality conditions expose their values. Done means rows created from filtered views receive matching single-value filter defaults, including when the filtered columns are hidden, with coverage for visible and hidden columns.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 56/100