tables
tables copied to clipboard
Adding a row to a filtered view does not set the filtered values
- Have a filtered view for a select value
- Create a new row
- Reload the page
- The new row has been added but the value the view is filtered to is not set
Can be seen in our feature tracking table with this filter:
Row after adding:
If I understand that correct, you want to set the filtered value additionally to the new row data, so the match the actual filter.
I would say this is not a bug, more a feature request, because we don't implemented this yet.
But, filter may be more complex than "team=office" and then it's might not be clear which value should be set. Think about filter like "date > today" or "Task contains abc"...
If we provide those fields in addition so they can be set if they are not that clear, that could be a data breach if something gets filtered in the back back secret values?! 😬
Agree that this is more tricky than just picking up the filter like for range/contains filters we would not be able to decide automatically on a default. Though I was wondering if for views that have simple equal filters we could still apply those values as defaults, but even figuring that out might be hard.
If we provide those fields in addition so they can be set if they are not that clear, that could be a data breach if something gets filtered in the back back secret values?! 😬
True, we should not let users pick if the column is not exposed to the view of course.
Do we have an insight how other solutions handle this?
A first idea could be to have a dedicated option to pick default values for new entries per view.
Do we have an insight how other solutions handle this?
No. Needs research. In Drupal it is possible to add values to load them for calculation but without presenting in the front end. But Drupal is an expert tool with a different approach...
A first idea could be to have a dedicated option to pick default values for new entries per view.
Yes, that sounds like a quick solution for that. But that would raise the complexity a lot and users might not know what that means?! Another idea could be a feature to hide columns in views. It would mean you can edit or create all data including hidden columns, but you don't see them in the table. That would fix the mentioned UC but not as a general solution?
I think this should be a validation, when adding a new row to a view. At least that was the behaviour I was expecting:
When adding a row to a view with filters, the added row must match the filters of the view, or it can't be created.
The current behaviour is the following:
When adding a row to a view with a filter, and the row does not match the filter, the row gets created and I can see it in the view after creating it. When reloading the page, I will not see it anymore, since the row does not match the view filters. This seems buggy to me (although I get why this is more of a feature request, than a bug).
I'm not sure if we can construct defaults just from filters (maybe only from simple ones with contains). We may instead just want to have an option to configure the defaults as the view creator. This also makes it more flexible to build workflows where a view creating puts the created row into a different view as the next step in the state flow.